Why you need to build security architecture into your enterprise

There is a massive divide between the understanding of security being an issue for government departments and the ability of management to decide how to best spend money to fix their infosec problems.

Is an investment in security architecture the answer?   

Last week, Western Australia’s Office of the Auditor General (OAG) released two audit reports relating to a number of WA government agencies.

The first report covered database security controls and revealed 115 significant findings, 15 of which were deemed extreme and 45 that were deemed high risk. Seven agencies were reviewed and the issues were catalogued in the following critical control areas.

                                                                     Image credit: OAG

The database security issues were reflective of a systemic issue seen in the report:

“We found several agencies did not separate their production, test and development environments. These environments replicated information from production (live) databases across all environments. This increases the attack surface by making the data more freely available to a wider pool of staff and contractors without the same level of security afforded to the production database.”

The reason this can occur is straightforward: maintaining multiple environments under change control and corporate governance is expensive.

Some time ago, I had to design a system that met security best practices and conformed well-specified security requirements and policy.

Initial planning took eons to get right, with a full test cycle factored into delivery to ensure we could prove all security requirements had been delivered into production.

The solution demanded a separate secure test environment that was representative of production, as well as a development environment for developers to experiment in.

However, once the bill of materials was created and the solution was priced, it was way more expensive than the customer had anticipated.

We then had to have that all too familiar 'environments' discussion, including questions like: 'do we really need three environments?' 'Why does the test system need its own network?' 'Why does test need to be so… representative of production?'

The resultant solution compromised on a number of requirements, the majority of which adversely affected the security posture of the enterprise; but at least the project was delivered on budget and on time.

Enterprise architecture doing security

Each of the 115 findings from the OAG’s database security report would have been addressed if the departments adopted security architecture as a discipline within their enterprise architecture (EA) function.

Requirements management is at the heart of EA, ensuring all work undertaken by the business delivers what’s needed from a strategic and tactical perspective.

A set of security controls must be created for the entire organisation, derived from policy, regulatory compliance and legal mandates and must be considered mandatory for every system and project.

A security architect will understand the complicated tensions between the business, policy, cost and delivery, and ensures the security of systems being delivered are never compromised for the sake of making delivery easier or getting into production quicker.

A typical security requirement might be stated as: "privileged access to a system shall be audited and alerted to the security operations centre in real time".

This might seem like a simple requirement to meet, however, each and every system in your enterprise must have the technical functionality to authenticate and authorise users in this way.

Your architects should be ensuring that every log entry related to this requirement is passed to your SOC, but ensuring comprehensive testing of requirements is built into the solution delivery lifecycle.

What if a system doesn’t have individual accountability? What solution needs to be built to ensure the requirement can be met in this case? Should the requirement be ignored to expedite delivery, or do you seek an alternative database that will meet the requirement?

The answer must be based on performing a technical risk assessment and taking a holistic look at the architecture rather than simply ignoring it or labelling it as too hard.

Hire an architect

If you’ve read through the OAG reports, it should be apparent that every organisation is suffering from the same underlying issue: they don’t have an overarching, systematic approach to delivering security into their enterprise.

The only way to start improving on the delivery of secure systems is to build security architecture into your EA function.

It needs to become second nature that your business analysts consult security at the beginning of any transformational planning, ensuring security principles, standards, requirements, best practices and legal obligations are identified for all projects and programmes.

But that’s not where it stops; make sure your security architecture capability is accountable for the delivery of system security right into production. Good practice starts at the concept stage and should never be traded out by underqualified technicians the closer it gets to production.

The OAG reports do a great job of opening our eyes to the defects in our current systems. And hopefully the agencies in question will fix all these problems and become stronger in the process.

However, it’s only through implementing a strategic security capability as part of the EA function that organisations will be able to deal with security holistically, and ensure the next year of change within the ICT environment doesn’t land them right back in the same place next year.