QA Cyber Security Technical Consultant, Graeme Batsman, looks at Intrinsic vs. Extrinsic Project and Programme Management.

Over the last few years I have worked on different accounts from massive corporations to central government departments. Sadly, I have seen all sorts of amusing situations, for those of you that think poor security as amusing. One thing in common across most organisations, when it comes to poor security isn't necessarily the employee's lack of experience but more to do with poor management or you guessed it…. Something which makes the world go around….cash.

Numerous in house or externally managed projects/programmes get little/no security oversight let alone a Pen Test. A project/programme will have an overall Manager/Director, various leads and resources. Think about it, if a programme with a budget of tens of millions has 100 full time staff for three years, can't it afford 1-2 full time security resources? Unfortunately more often than not, this isn't the case resulting in the security versus project team staffing ration to be poor.

I have worked on many projects where security has not been budgeted into the contract and in a best case scenario a security 'bod' is hired after three years which is really too late, and guess what? All I/they end up doing is managing a Pen Test only to have the results 'played down', so it does not delay the go-live date. Security should be ingrained from day one and be far more than just a test in the final week, which leads me to Intrinsic vs. Extrinsic.

Extrinsic
Think of the word external, i.e. seeing something from the outside only. This is the 'favourite' method because it is quick. On one recent project, it was down to the client to book the Pen Test, they emailed three well known security testing firms and got different day rates with varying days. Needless to say they picked the cheapest quote which included the testing and reporting in a single day… for under £1000! Who knows how you can test a web app properly in a single day and do the report too?

  • Pen Testing - as the be all and end all
  • Vulnerability Scanning - as a replacement for the above
  • Post Architecture Review - three years too late!
  • Paper Based Supplier Assurance - forgetting to look under the hood of suppliers

  • Intrinsic
    You guessed it, designing it from the inside, i.e. from day one not at the very end. This method costs extra in resources, time and possibly licenses. Me being a defensive techy on the same project as above nearly made the dev team faint by handing them over 110 items I wanted to tweak. I asked them what web CMS they were using and which hosting firm. Then I installed the web CMS myself, went through all the settings, wrote what I wanted changing and then went through online hardening guides to ensure nothing was missed. As well as reviewing the web host settings.

    What does good security involvement look like?
    • Involvement - invite him/her to all meetings and mailing lists, have a contact list and be social(!)
    • Gating - list deliverables and steps, and when they are required e.g. by x date with sign offs
    • Change Control - all changes of any size have to have a ticket raised and be signed off by change management and security
    • Supplier Assurance - don't assume firms with PCI and 27001 are half secure. Ask tough process and technical control questions too
    • Code Peer Review - have all code reviewed by someone else and if you don't have anyone, use a service (static/dynamic code analysis) or a specialist firm
    • Vulnerability Scanning - have this run against all apps and infrastructure at numerous stages to iron out flaws before Pen Tests
    • Pen Testing - make sure the tester is not just using a scanner without manual testing. Ensure prod environment is ready and that its tested
    • Data/Comms Management - developers are a wild (but nice) bunch and have a habit of using geeky SaaS without telling you. Ensure data is not saved to USBs, password vaults etc. and only approved collaboration tools are used. Communicate data/project classifications
    • Asset and Risk Registers - how can you protect what you don't know? List all assets and have a register of project risks, security and non-security risks
    • Architecture and Hardening Documents - have all general architecture reviewed by a security architect and have him/her design in security. Created standards for server configuration, encryption etc.