Marc Jones, VP of Public Sector, CAST and CISQ member

For cyber resilient software, you need to assess the system’s architecture. I’m stressing architecture because architecture can be overlooked. The current state of a complex system is rarely in line with design models, meaning system-level vulnerabilities may be lurking in the architecture.

Cyber resilience requires looking at the integrated technology stack, the history of the application, and the current deployed architecture. Traditional design for cyber resilience states that counter-measures should be designed and deployed at a central and protected location within the application. In reality, this can create performance bottlenecks and reliability  concerns – or even a single point of failure.

The best practice approach is to align specialized counter-measures to the data that must be validated and placed within dataflows of the application. This requires a better understanding of the architecture and governance for the unique context and constraints of each application. 

The 4 steps to fix and implement cyber resilient architecture:

1. Reverse-engineer the application and understand its architectural construction.
2. Remediate non-compliant architecture by refactoring faulty components.
3. Use coding standards from CISQ and define specific rules to monitor compliant target architecture.
4. Automate architecture checks and incorporate into the acceptance and integration phase of the development cycle.

Regarding step 3, the coding standards from CISQ include over 100 CWEs (software weaknesses) at the code and architecture level that are known to cause critical issues in software. CWE-424 "Improper Protection of Alternate Path" and CWE-1057 "Data Access Operations Outside of Expected Data Manager Component" are helpful to ensure that counter-measures for cyber resilience are applied in all situations.

The following illustrations show examples of common architectural construction for which such rules apply.

CWE-424 and its declinations validate that all the documented paths from user inputs to SQL, LDAP, OS, etc. type of resources must go through vetted sanitization components to prevent SQL, LDAP, OS, etc. preventing injection at any level.

CWE-1057 controls that databases accesses are using the designed architecture: all accesses are made using the Data-Access COB layer where cyber resiliency protections are located.

CAST has been a proud sponsor of CISQ and contributor to standards since 2010. For a demo on using CAST for architecture analysis, contact us at [email protected]. Your organization may qualify for a no cost CISQ assessment of one of your systems. View a sample report here.