Introduction to Security Architecture

Developed with
QA

Contents

keyboard_tab
Foundation Certificate in Cyber Security (FCCS)
2
Personnel Security
PREVIEW11m 23s

The course is part of this learning path

Foundation Certificate in Cyber Security
course-steps
5
certification
21
description
1
play-arrow
Introduction to Security Architecture
Overview
DifficultyBeginner
Duration33m
Students212
Ratings
4.5/5
starstarstarstarstar-half

Description

Course Description 

This course looks at the other facets of security that come into play when thinking about cyber security in generalStarting with physical and personnel security, it then moves into the secure development process, security best practice and ends with an introduction to security architecture.  

 

Learning Objectives 

The objectives of this course are to provide you with and understanding of: 

  • Physical security - lighting, CCTV, fencing, intrusion detection, screening, destruction, UPS and generators, access and control of entry 
  • People, employees, contractors, customers (resource, vulnerability, threat), recruitment, screening, Social Engineering, Common People Exploits, T&C's, in role, change in role, termination, insider threat, supply chain challenges 
  • Secure by Design, Secure Development Life Cycle (SDLC) 
  • Reduce the attack surface, defense in depth, test security, weaknesses and vulnerabilities, secure coding, learn from mistakes 
  • Security design architecture, enterprise design frameworks (TOGAF, ZACHMAN, SABSA), patterns (NCSC, Open Security Architecture) 

 

Intended Audience 

This course is ideal for members of cyber security management teams, IT managers, security and systems managers, information asset owners and employees with legal compliance responsibilities. It acts as a foundation for more advanced managerial or technical qualifications. 

  

Prerequisites  

There are no specific pre-requisites to study this course, however a basic knowledge of IT, an understanding of the general principles of information technology security, and awareness of the issues involved with security control activity would be advantageous. 

 

Feedback 

We welcome all feedback and suggestions - please contact us at support@cloudacademy.com if you are unsure about where to start or if would like help getting started. 

 

Transcript

Welcome to this video on Security Architecture. In it you’ll learn about Security Architecture, and look at some of the frameworks that exist for managing it.  

Firstly, let’s define what security architecture is. Simply put, it is the drawing together of the various ways to implement security into a single framework. On screen you can see the various areas in you could consider implementing a security solution, from the boundaries of the organization to controlling access to data. 

Security architecture entails the creation of a framework to implement security. To achieve this you need to identify those basic services which will provide security right now, and which could be integral in securing any new systems that come into operation. It will describe how systems need to behave, along with the required technologies that can secure the organizations assets. As the framework includes documenting this, it can provide a direct link between the organizations business needs and the implementation of identified controls. 

There are a number of standard frameworks that can be used. 

Five of the most popular architecture frameworks are: 

  • The TOGAF® Standard, a standard of The Open Group, is a proven Enterprise Architecture methodology and framework. 
  • DODAF and MODAF frameworks were created by government defence entities in the United States and the United Kingdom respectively. 
  • The Zachman architectural framework was created by John Zachman of IBM in the 1980’s. 
  • Sherwood Applied Business Security Architecture, or SABSA is a framework and methodology for enterprise security architecture and service management. It was developed independently from the Zachman Framework, but has a similar structure. 

This diagram shows the basic layout of the TOGAF model. The Preliminary Phase is about defining "how we do architecture" in the enterprise concerned. There are two main aspects: defining the framework to be used; and defining the architecture principles that will inform any architecture work. There are eight areas that feed into the overall requirements management process, providing a complete picture of the security requirements for the organization. The process is iterative, allowing for continual refinement and improvement. Each stage has a defined list of components that will assist in developing the response. 

This diagram is a represents the TOGAF meta-model.The content framework provides a structured model of building block types, relationships and attributes which can be used informally, or as the basis for configuration of an Enterprise Architecture modelling tool.  

It has the following benefits added to TOGAF: 

  • It provides a comprehensive checklist of architecture outputs 
  • It promotes better integration of work products if adopted across an enterprise 
  • It provides a detailed open standard for how architectures should be described 

This diagram shows the Zachman framework. It lists five key areas for consideration down the left. Across the top, it lists the key questions that need to be asked when considering any one of these areas, and below each is an answer. Feel free to pause the video and read through them.  

As is clear from the diagram, the SABSA model is very similar to the Zachman model but with the addition of a new area for consideration – Operational. Again, the main questions in relation to these are listed along the top, with the means of achieving answers for each area of consideration detailed in the column below. 

Although I have stated that security and Information Assurance have only come to the fore relatively recently, it should be noted that Information Assurance was being thought of as long ago as the mid 1970s. 

Saltzer and Schroeder published a list of security principles in an article titled ‘The Protection of Information in Computer Systems’. 

They listed eight security principles, as follows:  

  • Economy of mechanism – Any system should be as simple as possible, whilst still being secure. 
  • Fail-Safe defaults – decisions made about granting access should be based on permissions, not exclusions. 
  • Complete mediation – authorisation checking should not be a one-time effort. There should be a mechanism for regularly verifying authorisation. 
  • Open design – the design of the system should not be kept secret. This can be difficult to achieve when intellectual property protection comes into the equation 
  • Separation of privilege – there should be no unnecessary sharing of elevated privileges.  
  • Least privilege – all users of the system should carry out their work using the minimum level of required to enable them to achieve their goals 
  • Least common mechanism – code should not be re-used whenever possible to avoid it. This concept also links back to separation of privilege for users. 
  • Psychological Acceptability – security should not be so onerous for users that they invent ways to circumvent it. 

This brings us to the end of this video.  

 

 

About the Author
Students1694
Courses5
Learning paths5

Paul began his career in digital forensics in 2001, joining the Kent Police Computer Crime Unit. In his time with the unit, he dealt with investigations covering the full range of criminality, from fraud to murder, preparing hundreds of expert witness reports and presenting his evidence at Magistrates, Family and Crown Courts. During his time with Kent, Paul gained an MSc in Forensic Computing and CyberCrime Investigation from University College Dublin.

On leaving Kent Police, Paul worked in the private sector, carrying on his digital forensics work but also expanding into eDiscovery work. He also worked for a company that developed forensic software, carrying out Research and Development work as well as training other forensic practitioners in web-browser forensics. Prior to joining QA, Paul worked at the Bank of England as a forensic investigator. Whilst with the Bank, Paul was trained in malware analysis, ethical hacking and incident response, and earned qualifications as a Certified Malware Investigator, Certified Security Testing Associate - Ethical Hacker and GIAC Certified Incident Handler. To assist with the teams malware analysis work, Paul learnt how to program in VB.Net and created a number of utilities to assist with the de-obfuscation and decoding of malware code.

Covered Topics