SABSA Architecture and Design Case Study

Let’s talk about applying the SABSA framework to design an architecture that would solve a specific business problem.  In this blog post I’ll be using a fictitious example of a public sector entity aiming to roll-out an accommodation booking service for tourists visiting the country.

To ensure that security meets the needs of the business we’re going to go through the layers of the SABSA architecture from top to bottom.

Business View Contextual Architecture
Architect’s View Conceptual Architecture
Designer’s View Logical Architecture
Builder’s View Physical Architecture
Tradesman’s View Component Architecture

Contextual architecture

Start by reading your company’s business strategy, goals and values, have a look at the annual report. Getting the business level attributes from these documents should be straightforward. There’s no need to invent anything new – business stakeholders have  already defined what’s important to them.

Every single word in these documents has been reviewed and changed potentially hundreds of times. Therefore, there’s usually a good level of buy-in on the vision. Simply use the same language for your business level attributes.

After analysing the strategy of my fictitious public sector client I’m going to settle for the following attributes: Stable, Respected, Trusted, Reputable, Sustainable, Competitive. Detailed definitions for these attributes are agreed with the business stakeholders.

Conceptual architecture

Next step is to link these to the broader objectives for technology. Your CIO or CTO might be able to assist with these. In my example, the Technology department has already done the hard job of translating high-level business requirements into a set of IT objectives. Your task is just distill these into attributes:

 

Objectives

Now it’s up to you to define security attributes based on the Technology and Infrastructure attributes above. The examples might be attributes like Available, Confidential, Access-Controlled and so on.

Requirements tractability

The next step would be to highlight or define relationships between attributes on each level:

Attributes

These attributes show how security supports the business and allows for two-way tracebility of requirements. It can be used for risk management, assurance and architecture projects.

Back to our case study. Let’s consider a specific example of developing a hotel booking application for a public sector client we’ve started out with. To simplify the scenario, we will limit the application functionality requirements to the following list:

ID Name Purpose
P001 Register Accommodation Enable the registration of temporary accommodations available
P002 Update Availability Enable accommodation managers to update availability status
P003 Search Availability Allow international travellers to search and identify available accommodation
P004 Book Accommodation Allow international travellers to book accommodation
P005 Link to other departments Allow international travellers to link to other departments and agencies such as the immigration or security services (re-direct)

And here is how the process map would look like:

Process map

There are a number of stakeholders involved within the government serving international travellers’ requests. Tourists can access Immigration Services to get information on visa requirements and Security Services for safety advice. The application itself is owned by the Ministry of Tourism which acts as the “face” of this interaction and provides access to Tourist Board approved options. External accommodation (e.g. hotel chains) register and update their offers on the government’s website.

The infrastructure is outsourced to an external cloud service provider and there are mobile applications available, but these details are irrelevant for the current abstraction level.

Trust modelling

From the Trust Modelling perspective, the relationship will look like this:

Trust

Subdomain policy is derived from, and compliant with, super domain but has specialised local interpretation authorised by super domain authority. The government bodies act as Policy Authorities (PA) owning the overall risk of the interaction.

At this stage we might want to re-visit some of the attributes we defined previously to potentially narrow them down to only the ones applicable to the process flows in scope. We will focus on making sure the transactions are trusted:

New attributes

Let’s overlay applicable attributes over process flows to understand requirements for security:

Flows and attributes

Logical Architecture

Now it’s time to go down a level and step into more detailed Designer’s View. Remember requirement “P004 – Book Accommodation” I’ve mentioned above? Below is the information flow for this transaction. In most cases, someone else would’ve drawn these for you.

Flow 1

With security attributes applied (the direction of orange arrows define the expectation of a particular attribute being met):

Flow 2

These are the exact attributes we identified as relevant for this transaction on the business process map above. It’s ok if you uncover additional security attributes at this stage. If that’s the case, feel free to add them retrospectively to your business process map at the Conceptual Architecture level.

Physical architecture

After the exercise above is completed for each interaction, it’s time to go down to the Physical Architecture level and define specific security services for each attribute for every transaction:

Security services

Component architecture

At the Component Architecture level, it’s important to define solution-specific mechanisms, components & activities for each security service above. Here is a simplified example for confidentiality and integrity protection for data at rest and in-transit:

Service Physical mechanism Component brands, tools, products or technical standards Service Management activities required to manage the solution through-life
Message confidentiality protection Message encryption IPSec VPN Key management, Configuration Management, Change management
Stored data confidentiality protection Data encryption AES 256 Disk Encryption Key management, Configuration Management, Change management
Message integrity protection Checksum SHA 256 Hash Key management, Configuration Management, Change management
Stored data integrity protection Checksum SHA 256 Hash Key management, Configuration Management, Change management

As you can see, every specific security mechanism and component is now directly and traceable linked to business requirements. And that’s one of the ways you demonstrate the value of security using the SABSA framework.

Advertisements

Using SABSA for application security

Aligning OWASP Application Security Verification Standard and SABSA Architecture framework.

OWASP Application Security Verification Standard (Standard) is used at one of my clients to help develop and maintain secure applications. It has been used it as blueprint create a secure coding checklist specific to the organisation and applications used.

Below is an excerpt from the Standard related to the authentication verification requirements:

OWASP

The Standard provides guidance on specific security requirements corresponding to the Physical layer of the SABSA architecture.

SABSA views

As there’s no clear link to the business requirements, let’s perform alignment between two frameworks.

The first step is to gain an understanding of Contextual and Conceptual architectures.

From analysing the company’s corporate strategy I was able to derive multiple business attributes relevant to the shareholders:

Business attributes

After a workshop with the CIO and IT managers in various business units, I’ve defined the following IT attributes supporting the main business attributes and the relationships between them:

Business and iT attributes

How does the security function support the wider IT objectives and corresponding attributes? After a number of workshops and analysis of the security strategy document I’ve created a number of security attributes. Below is an example correlating to the business and IT attributes in scope:

security attributes

The next step is to develop the security attribute mapping to the requirements of an in-house application security policy, based on the OWASP Application Security Verification Standard:

Requirement Requirement Description
Authenticated
A1 Application must use established corporate directory services for authentication i.e. LDAP.
A2 Authentication must be performed over a secure connection like SSL/TLS to avoid data sniffing.
A3 Authentication mechanism must not store sensitive credentials on the client.
A4 Authentication credentials must not be submitted using URL parameters to avoid sniffing.
A5 Authentication failure response must never indicate which part of the authentication data was incorrect to prevent username enumeration.
A6 Password entry fields must enforce a combination of upper-case, lower-case, special-chars, numbers and a minimum length for secure password.
A7 All authentication controls must be enforced on the server side because it’s easy to tamper with data on the client side.
A8 Authentication credentials must be salted and stored using industry defined and proven hashing techniques.
A9 Forgot password and other recovery paths must send a link including a time-limited activation instead of the password itself.
A10 There must be no secret question and answer mechanism for resetting the password to thwart social engineering attacks.
A11 Forget password functionality must not disable the login for valid users to ensure valid users don’t get locket out.
A12 Authentication mechanism must define the account lockout policy in case of 3 to 5 wrong login attempts to avoid brute-force attacks.
Authorised
B1 Access Control process must be defined, agreed upon, and effectively implemented. The process must cover user authorization management, roles and responsibilities, and access revocation and expiry.
B2 The authorization business roles must be defined and documented.
B3 Authorization controls must be designed using the Principle of Least Privilege i.e. a user should not be granted excess privileges which is not required to perform his job.
B4 Business roles must never have authorization to perform application administration functions.
B5 An application must utilize a central component for authorization.
B6 Only trusted system objects must be used for making authorization decisions.
B7 Authorization check must be performed at every entry point of an application.
B8 Authorization controls must fail securely; all access must be denied if the application cannot access its security configuration information.
Managed
C1 The application must use the session management mechanism provided by the framework or server instead of a custom solution. Session management provided by the framework or server is thoroughly tested for security and hence safe to use.
C2 Session creation and management must be done on a trusted system and never on the client side.
C3 A new session must be established upon log-in and re-authentication to prevent session-fixation attacks.
C4 User must be forced to re-authenticate when attempting to access a function that requires elevated privileges.
C5 An idle session timeout and an absolute session timeout regardless of activity must be set.
C6 The logout function must explicitly terminate the user session and destroy all session related data.
C7 Session ids must have high entropy to avoid session id guessing attacks.
C8 The Session ID is sensitive; it must be protected and never displayed except in cookie headers.
C9 Session ID cookies must be marked as HttpOnly to avoid an XSS flaw from gaining access to it.
C10 User provided session ids must never be accepted.
C11 Concurrent session for the same user must not be allowed.
Validated
D1 All user-input coming from drop-down, text fields, value lists, and other UI components must be validated. By default the user input should be considered malicious.
D2 Special characters in input like (but not limited to) <, >, &, ’” if used in the output must be html escaped to make them context safe.
D3 Input validation and encoding must be performed on the server side.
D4 Queries passed to SQL databases must be parameterized or stored procedures should be used to prevent SQL injection attacks.
D5 All input validation failures must be logged to detect attack if any.
D6 Input validation failure message should not display any system or configuration information to the user. It may assist the attacker in profiling the system.
D7 Input validation failures must result in input rejection.
D8 File upload functions must be implemented securely. Uploaded file should be checked for virus and other malicious data
Controlled
E1 Error messages must not display any technical information about the application or the underlying infrastructure to thwart any attempt to profile the system.
E2 Application design must perform proper exception handling and must not solely rely on the underlying framework or infrastructure for handling errors.
E3 System resources that are no longer needed upon occurrence of an exception must be explicitly released.
E4 Application design must deny access by default.
Logged
F1 Logging controls must be implemented on a trusted system.
F2 Access to logs must be strictly controlled.
F3 Sensitive information must not be stored in system logs.
F4 Successful and unsuccessful login attempts must be logged.
F5 Attempts to access unauthorized sensitive transactions must be logged.
F6 Sensitive transactions and administrative actions must be identified and their usage logged.
F7 Unexpected application exceptions must be logged.
F8 Centralized monitoring of logs must be setup for critical applications.
F9 A log retention, access, and review process must be defined and effectively implemented.
Protected
G1 All sensitive data consumed and produced by an application must be classified and there should be a clear policy for access control to these data.
G2 The retention period must be obtained or determined for any data stored by an application.
G3 All sensitive information must be transmitted using the latest version of SSL/TLS.
G4 Only industry accepted encryption/hashing algorithms must be used. Outdated and weak hashing algorithm like MD5 should never be used.
G5 Data at rest must be protected by means of access control, and where required, by encryption
G6 Sensitive information must not be transmitted in GET query string or in URL parameter.
G7 User credentials must never be hard-coded or stored in config/plaintext files.
G8 An application must not reveal technical information about system components or underlying infrastructure.
G9 Unnecessary application code, documentation and components must be removed before deployment to production environment.
G10 Cookies sent over HTTPS must be marked as secure.
G11 Extranet applications must protect against Clickjacking attack by setting the iframe as same-origin in the cookie.
G12 Client side caching should be disabled for sensitive information using appropriate header or meta-tag like no-cache, Cache-Control, no-store.
G13 Temporary data or files must be invalidated after session termination.

Further aligning the application security policy to the SABSA framework, let’s invent the link between the SABSA layers, developing Logical, Physical and Component architectures:

Components

Note that the list of security requirements and control objectives is not exhaustive and presented for illustrative purposes only.

The Standard defines three security verification levels, with each level increasing in depth. Each ASVS level contains a list of security requirements. Each of these requirements can also be mapped to security-specific features and capabilities that must be built into software by developers.

Let’s map risk level for every security attribute and corresponding components to the Standard verification levels:

levels

The combined framework can now be used for high-level risk reporting:

dashboard

The OWASP framework is designed as a set of requirements to measure point-in-time compliance with the Standard. I propose widening the scope of the framework to include activities I performed above as part of the following lifecycle:

Cycle

Controls and control objectives are clearly defined in the Standard in order to address the risks, yet the focus on enablers to exploit potential opportunities is lacking. Below is an example of how a balanced approach might look like for the attribute Authenticated.

Attribute Enablement Objectives Control Objectives
Authenticated 1. Ensure that all essential enterprise information uses centralized authentication and access control mechanisms.

2. Encourage information creators and users to leverage centralized content repositories for all information essential to performing their day-to-day activities.

3. Where possible, use automatic assignment of information and data ownership and permissions to ensure information elements are accessed by only those individuals who have a legitimate business need.

4. Where possible, do not require users to explicitly manage individual access control permissions and authorizations.

Ensure that a verified application satisfies the following high level requirements:

1. Verifies the digital identity of the sender of a communication.

2. Ensures that only those authorised are able to authenticate and credentials are transported in a secure manner.

 

There is also a lack of metrics and performance targets in the OWASP Standard. To address this, I’ve developed a set of metrics and measurement approaches for security attributes with corresponding primary and secondary risk indicators. Below is an example for the attribute Authenticated.

Attribute Metric Measurement Approach Category Primary KRI Secondary KRI
Authenticated % of information elements stored in repositories, locations or on devices requiring authentication of some kind before the information can be accessed Audit of information repositories and storage locations.

 

Completeness 80% 90%
Authenticated % of applications using established corporate directory services for authentication Audit of web applications Completeness 80% 90%
Authenticated % of applications performing authentication over SSL/TLS Audit of web applications Completeness 80% 90%
Authenticated % of applications storing authentication credentials on the client. Audit of web applications Completeness 80% 90%
Authenticated % of applications enforcing password requirements Audit of web applications Completeness 80% 90%

How do you demonstrate benefits of the combined framework to the stakeholders?

The following stakeholders have been chosen to demonstrate features, advantages and benefits of the combined OWASP-SABSA framework as they are directly impacted by this change:

  • Chief Executive Officer (CEO) and the Board of Directors
  • Chief Risk Officer (CRO)
  • Chief Information Officer (CIO)
  • Chief Information Security Officer (CISO)

The table below provides a summary of benefits of the aligned framework.

Feature Advantage Benefit
CEO and Board CRO CIO CISO
Business-driven Value-assured Protects corporate reputation and Enables flexible fit with industry regulations Enables secure adoption of digital business model Facilitates alignment of application security efforts with business goals
Transparent Two-way traceability Ensures return on investment Enables effective compliance measurement approach Encourages integrated people – process – technology solutions Provides traceability of implementation of business-aligned security requirements
Auditable Demonstrates compliance to relevant authorities Demonstrates compliance to regulators and external auditors Ensures that compliance risk is effectively managed Facilitates effective internal information systems audits Supports application security and risk review processes

References:


Industrial Control Systems Security: Information Exchange

There are a number of global information exchanges related to industrial control systems security. They offer useful guidelines and standards to help protect the environment.

The UK Centre for the Protection of National Infrastructure (CPNI) provides good practice and technical guidance as well as advice on securing industrial control systems.
Secure move to IP-based Networks (SCADA):

They also highlight the risks of wireless connectivity of physical security systems

Similar information exchange centres were established in Japan and Spain,

For the introduction to Industrial Control Systems Security see my previous blogs (Part I, Part II, Part II) or ICS Security Library


Secure by design

V4tS8p5F_C0

Have you seen security controls being implemented just to comply with legal and regulatory requirements? Just like this fence. I’m sure it will pass all the audits: it is functioning as designed, it blocks the path (at least on paper) and it has a bright yellow colour just as specified in the documentation. But is it fit for purpose?

It turns out that many security problems arise from this eager drive to comply: if the regulator needs a fence – it will be added!

Sometimes controls are introduced later, when the project is well passed the design stage. It might be the case that they just don’t align with the real world anymore.

n0saycKzykM

Safety measures, unfortunately, are no exception. The solution may be poorly designed, but more often, safety requirements are included later on with the implementation not fit for purpose.

IbHF452Usk0tuLB7kjBazs

Same holds for privacy as well. Privacy professionals encourage to adopt the Privacy by Design principle. Is it considered on the image below?

2Tx1qKFQzfoB5nli4NoEG4


Global Industrial Cyber Security Professional (GICSP)

I’ve recently passed my GICSP exam. This certification is deigned to bridge together IT, engineering and cyber security to achieve security for industrial control systems from design through retirement.

This unique vendor-neutral, practitioner focused industrial control system certification is a collaborative effort between GIAC and representatives from a global industry consortium involving organisations that design, deploy, operate and/or maintain industrial automation and control system infrastructure.

GICSP assesses a base level of knowledge and understanding across a diverse set of professionals who engineer or support control systems and share responsibility for the security of these environments.

Here are some useful links for those of you who are interested in sitting the exam:

Exam FAQ

Flashcards

Certification Handbook


Sherwood Applied Business Security Architecture

I completed my SABSA Foundation training, passed the exam and earned the.SABSA Chartered Security Architect credential.

SABSA is a proven methodology for developing business-driven, risk and opportunity focused Security Architectures at both enterprise and solutions level that traceably support business objectives. It is also widely used for Information Assurance Architectures, Risk Management Frameworks, and to align and seamlessly integrate security and risk management into IT Architecture methods and frameworks.
SABSA is comprised of a series of integrated frameworks, models, methods and processes, used independently or as an holistic integrated enterprise solution, including:

  • Business Requirements Engineering Framework (known as Attributes Profiling)
  • Risk and Opportunity Management Framework
  • Policy Architecture Framework
  • Security Services-Oriented Architecture Framework
  • Governance Framework
  • Security Domain Framework
  • Through-life Security Service Management & Performance Management Framework

Teaching Information Security Concepts at KPMG

KPMG1

I delivered a 1,5-day Information Security Concepts course at KPMG UK.

We covered a wide range of topics, including information security risk management, access control, threat and vulnerability management, etc.

According to the feedback I received after the course, the participants were able to understand the core security concepts much better and, more importantly, apply their knowledge in practice.

Leron is very engaging and interesting to listen to
Leron has the knowledge and he’s very effective making simple delivery of a complex topic
Leron is an effective communicator and explained everything that he was instructing on in a clear and concise manner

There will be continuous collaboration with the Learning and Development team to deliver this course to all new joiners to the Information Protection and Business Resilience team at KPMG.