I remember (now it was a long time ago) when I worked in a support role and my dream job was being a technical architect, back in the warm and fuzzy days of no host-based firewalls, IPsec being something only MCPs knew about other than the networking team and when cybercrime was a shadow of how it is today.
It wasn’t until I had a few more notches under my belt when I realised that architecture in technology has different viewpoints, not only that but even the industry can’t agree on what things are or are not. That aside the reality is, is that architecture has different domains, specialisms, views, and viewpoints. I often find myself working across a whole range of areas, that is driven largely by specific customer requirements and scenarios (this is why I have a cool lab and lots of kit!)
When we consider a business technology system it has risk and by nature cyber security in that view. To think of this not being the case would be odd because ultimately “business” is the highest abstraction, and let’s think about what makes up a business:
- Mission, Vision, Goals and Objectives
- Strategy
- Information and Data
- Products and Services
- Assets
- Resources
- Supply Chain
- Finance
- People
- Divisions
- Departments
- Teams
- Individuals
- Capabilities
- Stakeholders
- Policies
- Process
- Capabilities
- Governance & Management
- Compliance
- Requirements
- Legal
- Regulatory
- Policy
- Customer
- Organizational
- Programmes
- Projects
- Customers
As part of the business governance and management as well as a range of other areas, risk management and technology make up components of the business architecture landscape.
The way I view organisations and businesses is from range of viewpoints and abstractions and focus areas.
In cybersecurity I often say the devil is in the details and whilst I firmly believe that it’s also in the details of how the cyber landscape looks at from a cross enterprise perspective. We need to consider this from a business landscape view all the way down to a technical landscape view.
When we think about different roles in business, we tend to segment things up:
- Leadership/Strategy
- Marketing
- Sales
- Legal
- HR
- Finance
- Research
- Operations
- IT
- Information Security
- Facilities
- Risk
- Physical Security
- Information Security
When we consider a security organisation there are common models and generic role definitions such as:
- SOC Analyst L1
- SOC Analyst L2
- SOC Manager
- Incident Response Manager
- Security Engineer
- Risk Manager
- Vulnerability Manager
- Junior Tester
- Penetration Tester
- Senior Tester
- Security Architect
- Security Designer
You don’t just have to take my word for this, there’s a UK government security professions career framework:
https://www.gov.uk/government/publications/the-government-security-profession-career-framework
When we look at the government guidance there are three levels/ranks of architect in the framework:
- Associate
- Architect Lead
- Architect Principal
Now inside that we have a link to skills:
Here we can go from:
- Awareness
- Working
- Practitioner
- Expert
And if we look, we must come to the realisation that there’s not only different types of architects at different levels, there’s also specialisms within each area. This is true even if you never saw the career pathway documentation, it’s a fundamental reality of how architecture in technology roles works.
- Enterprise Architecture
- Solution Architecture
- Technical Architecture
- Engineering
- Development
You can see here I’ve referenced engineering and development, why is this?
Well, we also need to think about more views:
- Software & Application Architecture
- Infrastructure Architecture
- Physical Security Architecture
What I’m getting at here is that there are a whole range of different types of architecture, and this also means that there are different types of security architecture and architects. Someone the other day said that security architecture was a “solution architect but security” but I have to say I don’t agree with this. Risk needs to be managed across the enterprise landscape and looking at security on a solution-by-solution basis as being the one ring to rule them approach to security architecture is certainly in my opinion, a flawed model.
The enterprise cyber landscape covers people, process, and technology. It’s the glue that links the digital business together in a risk managed and secure manner. It’s how both logical and technical controls combine, it’s most certainly not just solution-based architecture.
So, when we talk about cyber architecture, at least when “we” do, I’m talking about cyber security architecture from a range of perspectives:
This is more than just about an IPS, WAF or ensuring our code isn’t vulnerable to SQL injection (all of these are important) it’s about how cyber security works across the digital enterprise to identify, protect, detect, respond, and recover so that cyber security is an enterprise capability, a driving force for both risk management but also digital enablement.
The reality of this is that you must look at a 10,000 foot and 1 foot view, doing this however isn’t done on a dime. I can’t at least move my brain from 10,000 to 1 foot without a good few cups of tea, and a period of re-immersion. Therefore, we have teams of people working together, from developers to policy makers, enterprise cyber security architecture is arguably more about communication, strategy, and people more than regexes and python, but the reality is you need to, as an organisation, be able to do both!