The burden of proof

When a security architect makes a request for a security control to be implemented, the burden of proof is always on him/her. This proof can be provided in the form of a pointer to a security objective. The security objective will normally come from regulation or a standard (for compliance) or from a threat model (for actual security). A security control that does not serve towards an objective either indicates that an objective was overlooked, or indicates that the control itself does not serve towards a coherent security goal and shall thus be cancelled. For illustration, a requirement for a physical-attack countermeasure in a device that, by its threat model, is only deployed in a secure environment (and hence is not otherwise protected against simpler physical attacks), is probably a resource-waster. Requirements that are inconsistent with the threat model remind me of that well-known security comic of a tall heavy gate installed at the entrance of an area that has no fence around it at all.

Back in the 90’s and early 2000’s, you could utter on just about any requirement that “it’s for security”, and people immediately put a serious expression on their faces and nodded in agreement. Today, security needs to be expressed in terms of objectives, just like everything else that needs to be prioritized. (Okay, other than counterterrorism; the time of which will probably come in another decade or two.)

One backlog

Developers are not avoiding work by default. Their alleged tendency towards not-doing rather than doing does not really exist, or does not exceed that of the general population. They do avoid, however, spending resources on deliverables which are not measured anywhere. I don’t remember who was the first person to coin the phrase “what gets measured — gets done”, but he’s right. People who are measured by their deliverables tend to have limited appetite for spending resources on work that doesn’t count towards anything, and yet which takes time that could be invested elsewhere.

The above is trivial, and yet it is still surprising how many security teams publish their security requirements (or other requests) by means that form a separate channel into the development teams. It is true that security requirements are different from product requirements, but not so much in that both eventually compete on the same pool of resources; resources of which performance is measured by one metric rather than two.

Admittedly, it took me a few years to realize that, but for security work to get done, it needs to be fed into development teams through the same backlog that feeds the other product requirements. If a security request is part of the product mandate, then it should be fed along with the other product mandates, also playing within the same prioritization regime. If the request is not part of a product mandate, then it should probably not be treated as a requirement at all, at least until product priorities change to make room for it.

Security champions

Security champions are security-minded people who are part of the development teams, and who serve as ‘ambassadors’ of security within their respective organizations. Even if those champions are not officially announced, they often exist. It is common for development teams to have at least one person who is notably security minded, and who ends up being the bearer and promoter of security interests within the development team to which he/she belongs.

One cannot overstate the value of such security champions. They make the best mediators between the two teams. They know enough about the architecture, and yet they also understand and resonate with security concerns. The security champion is the person with whom members of both camps feel sufficiently acquainted and sufficiently trust. This is priceless.

Those security champions can become yet more useful if they are announced, or officially appointed, for a few reasons: First, a person who is officially treated as the security liaison is more likely to stick to this role also when it is less convenient. Second, this nomination can come with special training that the security champion is provided with, and perhaps also grant him/her a special title that can make it to the CV. Having a development engineer officially play an additional role in security governance is something all parties have interest in.

Iterative requirements specification process

Security requirements cannot be thrown over the fence; it just never works. Even if it could work, it does not encourage cooperation. When a security architect drafts a security requirement (or control), he/she should expect that when the rubber of that requirement hits the road of implementation, the proposed mechanism of the requirement might be found inefficient, if not outright infeasible as drafted. With this in mind, the first iteration of a specified requirement should be treated like a proposal, and the security architect writing it should treat oneself not as a regulator but as a negotiator. The next point illustrates how this state-of-mind can reflect in the way the requirement is written.

Requirements broken into normative and informative sections

Security specification is a unique task. It involves both art and science, when the security architect tries to map the descriptive security objectives of the various standards and threat models into prescriptive requirements that can be entered into Jira tickets and implemented by engineers. Some of this work calls for a strong security mindset and the ability to innovate. The other part of this task, however, the part where the actual requirement is specified, is one that heavily intersects with the role of the non-security developer (or architect). This part is where security engineering is less of black magic and more of traditional engineering. When specifying security requirements, the security architect, to a large extent, tells the developer how to do his/her job; seldom a recipe for domestic peace.

The way around this is by drawing a line that allows each party to be authoritative over what he/she is best in providing, and leave the common denominator for consensus. The best approach that I’ve tried to this end is to define security controls (or requirements) in two parts: a normative part and an informative part. The normative part consists of what shall be accomplished to meet the security objective. This is where the security architect can exercise his/her skills of pragmatically addressing security challenges. The ‘what’ section should be rather straightforward and point to a security objective that is, to a certain extent, non-negotiable. The informative part of the requirement is the place where the security architect can demonstrate his/her engineering skills and familiarity with the system, by defining a recommended how section, which achieves the what. In this section, the security practitioner provides a reference implementation, also as a quick proof that the requirement is attainable, at least in theory. The developer can appreciate the suggested architecture and implement it, or can take any other path that fulfills the normative part, optimally working on it together with the security practitioner. At least by my experience, this approach causes the least friction, it is the most inclusive, and it inspires healthy collaboration between people who are equally smart but who exhibit different perspectives.