11th February 2019

Security Testing

Reading Time: 2 minutes

It’s often the case that architects, especially those in the technical / solutions space find themselves giving recommendations on the appropriate levels of assurance that a project requires.

Certainly my experience has been that security teams, through their typically light-touch project involvement are reluctant to provide the kind of granular detail needed to, say, complete a pre-engagement survey form from a security testing company or lead discussions on the project’s behalf.

As with a lot of architecture balancing the often conflicting needs of project managers, programme leads and business sponsors while actually providing some genuinely useful assurance is an oddly interesting and delivering succinct, pre-digested words which accurately convey the technical realities is a challenge which I oddly enjoy.

It’s hard for project sponsors to turn a blind eye to the maelstrom of news surrounding information security and I remain convinced that if we were a bit more honest with ourselves that not ending up on the front page of the register is a valid non-functional requirement.

Some recent work in this space on a fairly innocuous internal-facing (but cloud hosted) mobile application triggered a few thoughts;

Has someone else tested this already? In my case this referred to the inference that we should re-test cloud components themselves such as the Web Application Firewall or API Manager. Cloud providers publish their own penetration testing results which in my view wholly satisfied our need for Infrastructure security assurance . Our limited test is unlikely to exceed that of a company the size of public cloud provider who has a significant reputation to protect.

Where things are policy driven, consider testing less. Got a fleet of well managed desktops, controlled by Group Policy and patched with a robust process. Consider testing far fewer of them.

Influence those around you to perform Operational Acceptance testing on new capabilities to reduce the ongoing testing burden. Key platform capabilities such as VPNs, Firewalls and networks can, in a lot of cases be expected to carry a suitable amount of inherent assurance. Consider only testing the delta changes, such as reviews of any configuration added.

Be clear about the scope and rules of engagement. It’s common for the words penetration testing and vulnerability assessment to be interchangeable. They have vastly different meanings.

Understand the motivations of those around you when proposing approaches. An important attribute of any architect is to understand the areas of focus for those who have skin in the game. Aim to give those around you the warm and fuzzy feeling.

As far as my current package of work goes, I think that about covers it. Agreeing the path forward was rather painless, overall. A friction-less engagement is always a good sign for success.

Share