Architecture Essays

I was asked recently by the head of a startup that’s providing security analytics to a large company how it could assess where there were gaps. It seemed lost in the various domains, actors, data repositories, applications, and infrastructure.

I know this problem well as an Enterprise Architect. I’ve come across several ways of assessing a company’s security maturity and applied a few of them. I thought it would be helpful to share the one I found most comprehensive yet clear, which I also provided to the startup above for its client.

There are various frameworks and techniques to assess enterprise security maturity. However, from my long experience, the assessment method of OWASP (Open Web Application Security Project) SAMM (Software Assurance Maturity Model) is robust in its coverage and independence from technology. It applies nicely across industries and various business and IT domains.

I am giving an outline below and a downloadable assessment template I created from the material. In practice, I modified the scoring levels to cover real-world situations better.

(All OWASP-SAMM materials are usable under Open Source and Creative Commons with Attribution, which allows me to share this information in a targeted way.)

5 Security Aspects and Their 3 Practices

The assessment framework considers security in five aspects and three dimensions to cover the entire life cycle — understanding the environment, the requirements, the solution design, the build, and operations.

Each of the 15 practices is then transformed into a scored questionnaire, which I have made into an Excel spreadsheet and linked after this section.

(For more understanding before you use the assessment template, you can visit the SAMM Model Website.)

It starts with what is usually an afterthought, the governance of the process and framework.

A. Governance

Governance focuses on the processes and activities related to how an organisation manages overall software development activities. More specifically, this includes concerns that impact cross-functional groups involved in the development and business processes established at the organisation level.

Practices of Governance

1. Strategy & Metrics (Without an overall plan, you might be spending a lot of effort to build in security, while in fact, your efforts may be unaligned, disproportional or even counterproductive. This practice aims to create an efficient and effective plan for realising your software security objectives within your organisation.)
2. Policy & Compliance (Focuses on understanding and meeting external legal and regulatory requirements while driving internal security standards to ensure compliance in a way that’s aligned with the organisation’s business purpose.)
3. Education & Guidance (Focuses on arming personnel involved in the software lifecycle with knowledge and resources to design, develop, and deploy secure software. With improved access to information, project teams can proactively identify and mitigate the specific security risks that apply to their organisation.)

B. Design

Design concerns the processes and activities related to how an organisation defines goals and creates software within development projects. It will generally include requirements gathering, high-level architecture specifications and detailed design.

Practices of Design

1. Threat Assessment (Focuses on identifying and understanding project-level risks based on the functionality of the software being developed and the characteristics of the runtime environment. From details about threats and likely attacks against each project, the organisation operates more effectively through better decisions about the prioritisation of initiatives for security. Additionally, decisions for risk acceptance are more informed, therefore, better aligned to the business.)
2. Security Requirements (Focuses on security requirements that are important in secure software. The first type deals with typical software-related requirements to specify objectives and expectations to protect the service and data at the application’s core. The second type deals with requirements relative to supplier organisations that are part of the development context of the application, in particular for outsourced development.)
3. Security Architecture (Focuses on the security linked to components and technology you deal with during the architectural design of your software.)

C. Implementation

Implementation focuses on the processes and activities related to how an organisation builds and deploys software components and treats their related defects. Activities within the Implementation function have the most impact on the daily life of developers. The joint goal is to ship reliably working software with minimum flaws.

Practices of Implementation

1. Secure Build (Emphasises the importance of building software in a standardised, repeatable manner and using secure components, including 3rd party software dependencies.)
2. Secure Deployment (One of the final stages in delivering secure software is ensuring the security and integrity of developed applications are not compromised during deployment. The Secure Deployment (SD) practice focuses on this.)
3. Defect Management (Focuses on collecting, recording, and analysing software security defects and enriching them with information to drive metrics-based decisions.)

D. Verification

Verification focuses on the processes and activities related to how an organisation checks and tests artefacts produced throughout software development. It typically includes quality assurance work such as testing and other review and evaluation activities.

Practices of Verification

1. Architecture Assessment (Ensures that the application and infrastructure architecture adequately meets all relevant security and compliance requirements and sufficiently mitigates identified security threats. In its more advanced form, the practice formalises the security architecture review process for architecture improvement, continuously evaluating the architecture’s security controls’ effectiveness, scalability and strategic alignment.)
2. Requirements-driven Testing (Aims to ensure that the implemented security controls operate as expected and satisfy the project’s stated security requirements. It does so by incrementally building a set of security tests and regression cases and executing them regularly. A vital aspect of this practice is its attention to positive and negative testing and misuse and abuse cases.)
3. Security Testing (Leverages the fact that while automated security testing is fast and scales well to numerous applications, in-depth testing based on sound knowledge of an application and its business logic is often only possible via slower, manual expert security testing.)

E. Operations

The Operations Business Function encompasses those activities necessary to ensure confidentiality, integrity, and availability are maintained throughout the operational lifetime of an application and its associated data. Increased maturity in this Business Function provides greater assurance that the organisation is resilient in the face of operational disruptions and responsive to changes in the operational landscape.

Practices of Operations

1. Incident Management (Once your organisation has applications in operation, you’re likely to face security incidents. In this model, we define a security incident as a breach, or the threat of an imminent breach, of at least one asset’s security goals due to malicious or negligent behaviour. Examples of security incidents might include — a successful Denial of Service (DoS) attack against a cloud application, an application user accessing the private data of another by abusing a security vulnerability, or an attacker modifying application source code. The Incident Management (IM) practice focuses on dealing with these in your organisation.)
2. Environment Management (Focuses on keeping your environment clean and secure.)
3. Operational Management (Focuses on activities to ensure security is maintained throughout operational support functions. The functions covered by this practice include system provisioning, administration, and decommissioning; database provisioning and administration; and data backup, restore, and archival.)

Assessment Spreadsheet

You can download and use the assessment sheet from my website at this link (with attribution to me and SAMM) ->

Enterprise Security Assessment EA Spreadsheet

(Clicking will open a new window and download the sheet. You can close the new window after the download completes.)

Here is an image of a part to see what it looks like.

Guidance

1. Who should fill out the assessment?

An EA, Security Consultant, or Senior Security Analyst.

2. Who should provide the information?

CISO, CIO, CTO.

3. When should the sheet be filled?

Every six months. And at the start of an EA engagement that includes security gap analysis.

4. What should be done with the findings?

Create a 1–2 year transformation plan, define prioritised projects, create a business case for each project, deliver the projects and improve the company’s security posture.

End Note

Doing something holistically and systematically creates quality, providing value and saving money and time. I hope you use this assessment sheet and what it reveals for your organisation. Or know it and get the right person to apply it.

Enjoy the architectural thinking, dear architect.

Enjoy the outcomes, dear company risk manager.