Security and Architecture

SUZANNE GRAHAM
 Why

 What

 How

 When
 Why
Information Security

Information Assurance has been more Security has four strands to

involved with assessing the overall risk enable determent
of an organisation's technology and
working to mitigate that risk.
Physical
Pillars generally considered to be; Personnel
Integrity Procedural
Availability Technical - Typical examples being;
Confidentiality Firewall
Non-repudiation Intrusion Detection/Prevention Systems
(Counter) Hacking
Authentication
Penetration testing
Vulnerability Analysis of systems
 Why
Security in architecture

Security architecture is a unified security design that addresses the necessities and
potential risks involved in a certain scenario or environment.
It also specifies when and where to apply security controls.
The design process is generally reproducible.

In security architecture, the design principles are reported clearly, and in-depth
security control specifications are generally documented in independent
documents.

System architecture can be considered a design that includes a structure and

addresses the connection between the components of that structure.

Source : Techopedia
 What
Security Architecture and Design

The design and architecture of security services facilitates the management of business risk
exposure objectives.
 Risk management
 Benchmarking and good practice
 Financial
 Legal and regulatory

Security Architecture is the design artefacts that describe how the security controls (= security
countermeasures) are positioned and how they to the overall systems architecture.
 What
Architectural Principles – Example set (Source : TOGAF)

Business Principles
Principle 1: Primacy of Principles
Principle 2 : Maximize Benefit to the Enterprise Data Principles
Principle 3: Information Management is Everybody's Business
Principle 4: Business Continuity Principle 9: Data is an Asset
Principle 5: Common Use Applications
Principle 6: Compliance with Law Principle 10: Data is Shared
Principle 7: IT Responsibility
Principle 8: Protection of Intellectual Property Principle 11: Data is Accessible
Application Principles
Principle 15: Technology Independence Principle 12: Data Trustee
Principle 16: Ease of Use
Principle 13: Common Vocabulary and
Technology Principles Data Definitions
Principle 17: Requirements-Based Change
Principle 18: Responsive Change Management Principle 14: Data Security
Principle 19: Control Technical Diversity
Principle 20: Interoperability
 What
Architectural Principles : Data Security (Source : TOGAF)

Principle 14: Data Security

Statement:
Data is protected from unauthorized use and disclosure. In addition to the traditional aspects of national security classification, this includes, but is not limited to, protection of pre-decisional, sensitive,
source selection-sensitive, and proprietary information.

Rationale:
Open sharing of information and the release of information via relevant legislation must be balanced against the need to restrict the availability of classified, proprietary, and sensitive information.
Existing laws and regulations require the safeguarding of national security and the privacy of data, while permitting free and open access. Pre-decisional (work-in-progress, not yet authorized for release)
information must be protected to avoid unwarranted speculation, misinterpretation, and inappropriate use.

Implications:
Aggregation of data, both classified and not, will create a large target requiring review and de-classification procedures to maintain appropriate control. Data owners and/or functional users must
determine whether the aggregation results in an increased classification level. We will need appropriate policy and procedures to handle this review and de-classification. Access to information based on
a need-to-know policy will force regular reviews of the body of information.

The current practice of having separate systems to contain different classifications needs to be rethought. Is there a software solution to separating classified and unclassified data? The current
hardware solution is unwieldy, inefficient, and costly. It is more expensive to manage unclassified data on a classified system. Currently, the only way to combine the two is to place the unclassified data
on the classified system, where it must remain.

In order to adequately provide access to open information while maintaining secure information, security needs must be identified and developed at the data level, not the application level.

Data security safeguards can be put in place to restrict access to "view only", or "never see". Sensitivity labeling for access to pre-decisional, decisional, classified, sensitive, or proprietary information
must be determined.

Security must be designed into data elements from the beginning; it cannot be added later. Systems, data, and technologies must be protected from unauthorized access and manipulation. Headquarters
information must be safeguarded against inadvertent or unauthorized alteration, sabotage, disaster, or disclosure.

Need new policies on managing duration of protection for pre-decisional information and other works-in-progress, in consideration of content freshness.
 How
Attributes of Security Architecture

 Relationships and Dependencies: Signifies the relationship between the various

components inside IT architecture and the way in which they depend on each other.
 Benefits: The main advantage of security architecture is its standardisation, which makes it
affordable. Security architecture is cost-effective due to the re-use of controls described
in the architecture.
 Form: Security architecture is associated with IT architecture; however, it may take a
variety of forms. It generally includes a number of conventional controls in addition to
relationship diagrams, principles, and so on.
 There are four approaches.
 How – Approach 1
Open Enterprise Security Architecture (O-ESA)

It gives a comprehensive overview of the key security issues, principles,

components, and concepts underlying architectural decisions that are involved when
designing effective enterprise security architectures.

It does not define a specific enterprise security architecture, and neither is it a "how
to" guide to design one, although in places it does indicate some of the "how".
 How – Approach 2
Secure Collaboration-Oriented Architectures (O-
SCOA)

 This framework specifies the requirements for secure design of enterprise IT

architectures that support deperimeterized operations.

 This collates all the Secure COA Requirements Papers, along with the Jericho
Forum Commandments (design principles).

 It specifies all the essential components required for architecting secure

systems for deployment in de-perimeterized environments; i.e., without
depending on securing the corporate perimeter.
How – Approach 3
SABSA security architecture approach

This White Paper documents an approach to enhance the TOGAF

Enterprise Architecture methodology with the and thus create one
holistic architecture methodology.

This White Paper is intended to guide enterprise and security

architects in fully integrating security and risk management into
enterprise-level architectures, to stimulate review comments and
inform the global architecture community of proposed new content
from the SABSA perspective.
How – Approach 4
Architecture Risk Assessment

Evaluates the business influence of vital business

assets, and the odds and effects of vulnerabilities
and security threats.
 How
To achieve and support secure design
Architects need to;
 Interact with senior stakeholders across departments and will reach and influence a wide range of people across
larger teams and communities
 Research and apply innovative security architecture solutions to new or existing problems
 Develop vision, principles and strategy for security architects for one project or technology
 Work out subtle security needs and will understand the impact of decisions, balancing requirements and deciding
between approaches
 Produce particular patterns and support quality assurance, and is the point of escalation for architects below them
 Identify responsibility for leading the technical design of systems and services, and are able to justify and
communicate these design decisions
 Recommend security controls and identify solutions that support a business objective
 Provide specialist advice and recommend approaches across teams and various stakeholders
 Communicate widely with other stakeholders
 Advise on key security related technologies and assess the risk associated with proposed changes
 Inspire and influence others to execute security principles
 How
Roles & Responsibility of Enterprise Architect

Enterprise Architects maintain the organisational abstract view, with a

primary objective to ensure that the technology landscape is aligned
to the strategic, operational and tactical goals of the organisation.

 Strategic input into the technology roadmaps of the organisation – shape, form and stabilise.
 Insight – understanding the deficiencies of both products and services deployed in the technology landscape.
 Influence decision makers on technology investment – current & future.
 Provide systems consultancy, guidance and assurance to large programmes.
 Review and assure Solution Designs produced both internally and by 3rd party suppliers.
 Ensure that governance mechanisms such as review boards, principles etc. are maintained and supported.
 Police the standards through Project and Programme engagement.
 Represent the organisation with 3rd parties, for example Systems Integrators and Standards Bodies.
 Understand the impact of the introduction of new technology into the technology landscape of the organisation.
 How
An example of Technical Security
The term Public Key Infrastructure (PKI) is used to describe the processes, technologies and
practices that are required to provide a secure infrastructure.
A PKI could provide the following:
 Authentication: This can be defined as a means of identification. PKI offers this through digital
certificates.
 Non repudiation: The basis of non-repudiation is that the sender cannot disown any
information sent at a later time. Non-repudiation ensures that there is trustworthy means of
ensuring ownership of an electronic document. PKI offers non-repudiation through digital
signatures.
 Confidentiality: This can be defined as the secure transmission of information over networks
ensuring that it is not accessed by unauthorised individuals. PKI ensures confidentiality through
use of encryption algorithms.
 Integrity: The concept of data integrity is that data should not be altered of modified in any
way while traversing the network.
 Integrity of data is ensured by message hashing. Access Control: The idea of access control is
to ensure that only people with the required security privileges are allowed access to
information. PKI ensures access control through public and private key pair
When
Architecture and Security

Initial Concept
Business Case / Initial Scoping
Initial Review
When do you Business Analysis / Detailed Scoping
Design
think? Business Review
Build
Benefits Review
Organisational Review
Training
Deployment
Post Deployment Review