There are lots of articles about what’s required for security to flourish in an organisation. I thought I’d put together something inspired the Pragmatic Engineer article that’s specific to Security Architects. I’ve probably gone a little further to indicate the anti-pattern in the text…

General Technology Questions

Do you use low-priced/low spec commodity IT for your end user compute devices, with the idea that “people only need MS Office and a browser, right”?

This matters because when your primary productivity tool is poor, everything suffers. There is a view that laptops/screens are commodity and equally interchangeable. They are not. Even at the well-known brand level. There is a reason that big 3/big 4 consultancies given their people good quality IT; it isnt to look good in front of clients – its because they need maximum productivity.

Do senior people have ‘better’ IT than the majority of your staff?

This can be indicative that senior people are even more removed that necessary from the experience of shop floor staff. Senior leaders with tablets/2-in-1s or Macs (when everyone has low-end Windows PCs) are a clear sign of this.

General Security Questions

How often do you hear/experience the phrase “…yeah, but security made us do it…” when considering other technology events or outcomes in your estate?

This is most often experienced with some negative event that has been insisted upon by security people. An example could be an out-of-cycle patch, or a change to harden a configuration. It implies that the security team is some sort of unwanted body or enforcer and that their goals aren’t broadly shared.

Are security requirements and needs up for question and trade in the way that the needs of other disciplines are not?

This occurs mostly when a security team member says that a particular thing is required. It could be anything – a  specific password construction rule, possibly a specific configuration of a system component. This could be either the enforcement of a security standard or possibly the result of an architectural assessment. The cause of this one is similar to the point above – the security team are lesser beings and their goals arent broadly shared.

Is Security a valuable partner to your business, or a technology tax to be minimised and ideally eliminated?

The best way to see security is a valuable partner; perhaps the best way to articulate the way security – either alone, or in concert with Technology teams, can contribute to the top line of the business. This can come by way of customers choosing to buy from you over other some other company, or by keeping customers/regulatory questions at bay, by both good communication – and by actually doing demonstrably good security. There are a number of tools in use by customers to monitor their actual and potential supplier’s security posture. If there are exceptions – be transparent as to why they are there.

Does your board/senior (non-IT/security) leadership understand that you are dealing with an adversary that is to some extent – unknown/unpredictable/mostly unquantifiable.

Does your (non-security) technology leadership truly understand that the actions of their staff can undermine the work of the security team. For example – a QA/test team arent impacted if you release a product with little testing – the application/software owners are. That’s not how it is in security. Other people do sub-optimal things which harm security posture – blame security.

Security Architect Specific Questions

Are your security architects (and their input) valued as part of the design approach to systems development work? Or are they corporate policemen who you only look to approve things – without permitting discussion?

This is a common issue with security architects. They tend to be rare beasts, and spread very thinly across any number of projects or products. The idea of a single security architect on a single product may exists in Silicon Valley – but here in reality – much less so. This leads to a “lets run it past security” which in effect means “we’ve already taken the decision, talked ourselves out of plausible alternatives and already started work”…pushing water uphill right from the beginning.

Do you have an inclusive design approach, ie you get inputs from relevant technology disciplines at the right time?

The word inclusive in the statement above is doing a lot of work. When systems or change is being designed, there are a number of sources of thematic requirements in any large company. The method by which those disciplines are able to input to a design and know that what they’ve asked for has or hasn’t been delivered is key.

Do you have a corporate risk assessment/business impact assessment method that is used BEFORE (and possibly during) the design process – the results of which are an input to the architecture and design process?

This is important, because it attempts to ground the requirements of the design in reality as close as possible. There is always interpretation, but is better than “this is what <architect> thinks. Also, does this approach use empirical evidence as to the nature of the attacks the organisation suffers from – whether that’s is targeted Internet-borne attacks, or some questionable goings-on in a certain department?

Is the competence of your security architects the first question asked, when a system is breached?

Many reasons may be behind a breach, it could be an issue that has been overlooked in the usual project pressures to deliver everything yesterday. Blaming your security architects (who may be spread across tens of projects at any one time) for a breach which may have occurred months after a system went live – is scapegoating. This is akin to blaming a car manufacturer when a car breaks down after five years of running. It could be a design-time/manufacturing fault, but it could also be a maintenance item that’s been missed in recent months.  

Is the work of your security architecture team understood and valued by other teams/disciplines in your security function?

In security functions that largely manage various security or infrastructure tools, the security architecture team can stand out. They don’t fit in a non-technical group like GRC, but not are they ‘on the tools’. This can lead to a position where the team’s role isn’t well understood. This is exacerbated by the teams primary communication being with their customers – the various parts of the enterprise doing technology development in some form. This leads to the death spiral of random tasking, overwork and noises around “what does that team do”. In which case – either abandonment of the function or constant staff churn soon follow.

Do you view security architects as the skilled generalists who can be the ’expanding foam’ that tackle randomness in your tooling-centric security function?

This is related to the previous question. Often in tooling-centric security departments, there is a need for some group of folk to ‘do things’ that arent related to on-boarding systems on the tools/fettling the tools/bidding for money to get better tools. This random tasking – or expanding foam work (as I like to call it) often falls to security architects. If you’ve experience of a large delivery project – this is akin to the integration authority role. Without it, the specialists sink back into their chosen part of the Venn diagram.

Do you have an Enterprise Security Architecture function? Does it plot/guide/influence the security approach your organisation takes?

It’s probably fair to say that Enterprise Security Architecture, and by extension Enterprise Security Architects are a rare beast. At least when they are doing what they should. Like any other Enterprise Architect – the role is about seeing where the future is going, managing the positions of various solutions and providing guidance to the various solution teams. Enterprise (Security) Architecture is about “building the right thing” whereas Solution (Security) Architecture is about “building the thing right”.

Do you ask for experience with various frameworks during hiring, but then shun/ignore/mostly ignore them in day-to-day work, or perhaps only use them for compliance demonstration, rather than actively contributing to your security posture?

Often during recruitment, organisations ask for experience with various frameworks – security or otherwise. Good examples are TOGAF, SABSA, NIST CSF, or perhaps some others for specific technology or industry. Oftentimes, these are either not adopted, or partially adopted by the organisation. If you try to actively use them inside the organisation, once hired – people then decry the framework as ‘too heavy’ or ‘academic’. Safe in the misplaced knowledge that their way is best…

Its entirely possible I might think up others to these – perhaps there might be a follow-up post.