Security Design: Be an enabler not a blocker

Matthew Hackling

Matthew has over ten years experience operating solely in the area of information security, holds a Bachelors degree in security management from ECU and is also a CISSP. He is a former Account Director in Deloitte’s Security & Privacy Services practice. Matthew has led security testing teams on assessments of large core systems replacement projects for banking institutions. He operates more in the area of information security governance these days, despite his urges still stay a bit technical. Hence he plays with backtrack linux, metasploit and new web application security assessment tools in his rare free time. Currently he runs his own consultancy called Ronin Security Consulting and holds the title of General Manager of Security Testing at Enex TestLab. He is an active member of the Australian Information Security Association, and held the office of Melbourne Branch Executive for a number of years. Matt’s security blog is called Infamous Agenda and he is an active twitter user with the handle @mhackling

When liaising on projects, as a security architect it’s important to not spring surprises on your project manager. Most project managers tend to react with an involuntary facial twitch to "new requirements", these are often are associated with project delays and cost overruns.

So to avoid surprises and make your engagements with a project smoother, consider the following:

1. Engage early
2. Draw out compliance requirements early in the business case phase
3. Develop detailed security requirements that are specific and technology agnostic. Also, detail the importance and difficulty/cost of the controls at a high level. (Eg. not so much: “the system must be secure”, but more like: “the system must support TLS for protecting transit of classified information”.
4. Give the project options even when they are limited. For example: "You need this control for compliance purposes but it’s difficult to implement in the project timeframe, can I help you apply for a temporary security policy exemption?”
5. Choose standardisation over specialisation. A standard security control inherited from an environment is more likely to be maintained than a custom one deployed only for a single project.