Security and Architecture SUZANNE GRAHAM

Security and Architecture SUZANNE GRAHAM

Why What How When

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

Source : Techopedia 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.

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 Principle 3: Information Management is Everybody's Business Principle 4: Business Continuity Principle 5: Common Use Applications Principle 6: Compliance with Law Principle 7: IT Responsibility Principle 8: Protection of Intellectual Property Application Principles Principle 15: Technology Independence Principle 16: Ease of Use Technology Principles Principle 17: Requirements-Based Change Principle 18: Responsive Change Management Principle 19: Control Technical Diversity Principle 20: Interoperability Data Principles Principle 9: Data is an Asset Principle 10: Data is Shared Principle 11: Data is Accessible Principle 12: Data Trustee Principle 13: Common Vocabulary and Data Definitions Principle 14: Data Security

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 When do you think? Initial Concept Business Case / Initial Scoping Initial Review Business Analysis / Detailed Scoping Design Business Review Build Benefits Review Organisational Review Training Deployment Post Deployment Review