Purpose

To conduct a solution review we need to consider multiple perspectives. Cyber security can be described as (from the NCSC):

“Cyber security’s core function is to protect the devices we all use (smartphones, laptops, tablets and computers), and the services we access – both online and at work – from theft or damage. It’s also about preventing unauthorised access to the vast amounts of personal information we store on these devices, and online.”

Cyber Security is concerned with risks, threats, vulnerabilities, and controls. This really means the breadth and depth of cyber security is vastly wide and terribly deep.

The Cyber Landscape at high level

So, let’s think about the cyber landscape, at a high level we can break the landscape down in the following manner:

• Assets (The things we are trying to protect)
  • Data/Information
  • Services
  • Devices
  • People
• Vulnerabilities (The weaknesses that can or may exist)
• Exploits (The mechanisms by which the weaknesses are exploited)
• Threat Actors (The causes of threats, this can include environmental)
• Threats (Negative impact events)
• Risks (A scenario of the above)
• Controls (Measures to combat the threats, threat actors, exploits and vulnerabilities)

Perspectives

Cyber and Information Security are broadly concerned with the security of a service in relation to:

• Confidentiality
• Integrity
• Availability

These are commonly known as the CIA Triad. Different contexts will generally give an order of priority to these. Commonly A, I, C can be viewed as a traditional order of importance to common business scenarios, however it’s dependent upon many things.

Purpose of a design review

A design review can be triggered by a range of requirements but it’s common as part of the service planning and design phases to consider reviewing services and solutions to ensure:

• They are fit for purpose
• That the risks are known and understood
• That the solution meets the business needs
• That it has suitable controls regarding risks

Design Review Considerations

A major consideration here is the scope of activity and exercise. In addition to this it is wide to review things with a view on:

• Risk Appetite
• Risk Tolerances
• Business Outcomes
• Security Outcomes
• Constraints

A custom web application holding sensitive data may warrant a greater level of review than a simple component or COTS application. It should be risk aligned.

Review Perspectives

We should consider a range of views and perspectives which include:

• Customer
• Supply Chain
• Operations
• Financials
• Legal and Regulatory
• Corporate Policy
• Procurement and Support
• Value
• Risk
• Controls
• Supply Chain

Supplier Considerations

• Supply Chain Security
• Accreditations
  • ISO27001:2013
  • Cyber E
  • IASME
  • SOC2
  • ISO9001
• Risks
• Location
• Countries of Operation

Product/Service Considerations

• Requirements
• Governance
  • Policies
• Compliance & Assurance
  • Common Criteria/EAL
  • Penetration Testing
  • Code Review
  • Product Assurance Certifications
• Operations
  • Security Monitoring
  • Reporting
  • Operator Requirements
    • Skills
    • Certifications
    • Training
    • Documentation
  • Configuration
    • Vendor Hardening Guidance
  • Vulnerabilities/Vulnerability History
  • Digital Forensics/Chain of Custody Considerations
• Integration
• Features
  • Product/Service Specific Features
• Financials/Costs
• Interfaces
  • User
  • Administrator
• Authentication
  • IAM, PAM, RBAC
• Authorization
• Data Protection
  •  Data Location
  • Access to services/data
  • Encryption at Rest
  • Encryption in Transit
• Firmware
  • Frequency of Firmware Updates (historic)
• Patching and Updates
• Physical Security
• Audit Logs
• Reporting
• Alerting
• Product Roadmap
• Product Lifecycle and Supportability
• Warranty
• Performance
• Availability/HA Options
• Backup and Recoverability
• Supply Chain
• Secure Wipe/Destruction

There’s quite a bit to think about. Whilst you can silo out some of the areas and say some are IT and some are Security that to me is an odd approach. It would be better from my point of view to just consider leveraging different skills, tools, and techniques. If we look at security in isolation without the context, we will almost certainly not be able to understand the solution and therefore we won’t be able to understand the risks etc.

A lifecycle Approach

We need to think of the product or service in line with a lifecycle. This is clearly a generic view, but it lines up with the service lifecycle that everyone should be familiar with:

Plan	Design	Build & configure	Operate	Retire
> Vendor Due Diligence > Service/Solution/Product Due Diligence > Risk Assessment > Threat Modelling > Asset Classification	> “Design Review” – Architecture Review – Security Controls Review – Integration Review	> Vulnerability Assessment > Application Security Testing > Infrastructure Testing > Code Review > Security Operations Testing	> Penetration Testing > Adversary Simulation > Red Teaming > Purple Teaming	> Secure Disposal/Media Sanitation

For a fun exercise look at how many things often don’t occur, but also, we’ve got penetration testing in operate but we have it in build & configure as well, just with a different name. There are also other process linkages to each phase to consider such as portfolio management, change and release management etc.

Summary

This is a bit of a brain dump; we can probably carve this up differently and make a “checklist” approach but my intention here was more to open the thought process and get people thinking about the types of things they need to consider rather than being a tick box exercise for understanding systems and security.

Hopefully this gives people a bit of insight into the thought process I have and helps people think about system planning, design and operation from both an IT and cyber security perspective.