Portcullis Labs » devsecops https://labs.portcullis.co.uk Research and Development en-US hourly 1 http://wordpress.org/?v=3.8.5 Security Engineering – A manifesto for defensive security https://labs.portcullis.co.uk/presentations/security-engineering-a-manifesto-for-defensive-security/ https://labs.portcullis.co.uk/presentations/security-engineering-a-manifesto-for-defensive-security/#comments Fri, 28 Jun 2019 06:27:47 +0000 https://labs.portcullis.co.uk/?p=6858 Presentation on the need to re-examine how we engineer systems (taking service providers as an example) and the implications on how we quantify cyber risk if we want to take this message into the board room (as given at BT’s SnoopCon 2019 and Cisco’s June 2019 Knowledge Network webinar for service providers). Having delivered security […]

The post Security Engineering – A manifesto for defensive security appeared first on Portcullis Labs.

]]>
Presentation on the need to re-examine how we engineer systems (taking service providers as an example) and the implications on how we quantify cyber risk if we want to take this message into the board room (as given at BT’s SnoopCon 2019 and Cisco’s June 2019 Knowledge Network webinar for service providers).

Having delivered security consultancy as part of Portcullis/Cisco for over 15 years, I’ve seen a variety of shades of broken. Since I recently spent some time on secondment to one of our customers to help them design, build and operationalise security as part of their digital transformation programme, I got to thinking: what would I do if I wanted to get projects delivered right? With apologies to grsec, Jericho Forum, BeyondCorp and Trusted Computing, what followed was part philosophy, part technical brain dump, the result being my take on security engineering and how to build defensible systems. This talk includes the following hits:

  • Helping the blue team – a case study in 3 parts…
  • Blue doesn’t have the man power to adopt gift wrapped improvements let alone offensive research thrown over the wall
  • Static passwords – why the hell are we still using them?
  • Vulnerability management – didn’t we say blacklists were bad?
  • Forget about penetration testing – what are your controls?
  • Is there another way to report – why don’t businesses listen to us?
  • Monetising MITRE – can we make money out of CVEs?
SEAMFDS
SEAMFDS.pdf
June 28, 2019
311.8 KiB
MD5 hash: 185701fbc113ca2a676e802b61df53e2
Details

The post Security Engineering – A manifesto for defensive security appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/presentations/security-engineering-a-manifesto-for-defensive-security/feed/ 0
Use Infrastructure as Code they said. Easier to audit they said… (part 1) https://labs.portcullis.co.uk/blog/use-infrastructure-as-code-they-said-easier-to-audit-they-said-part-1/ https://labs.portcullis.co.uk/blog/use-infrastructure-as-code-they-said-easier-to-audit-they-said-part-1/#comments Sat, 26 Jan 2019 22:06:06 +0000 https://labs.portcullis.co.uk/?p=6839 Whilst there are some great examples of how to assess infrastructure as code dynamically with things like the Center for Internet Security‘s Docker benchmark and CoreOS‘s Clair, these kinda run a little too late in the pipeline for my liking. If we want to treat infrastructure as code then surely we ought to be performing […]

The post Use Infrastructure as Code they said. Easier to audit they said… (part 1) appeared first on Portcullis Labs.

]]>
Whilst there are some great examples of how to assess infrastructure as code dynamically with things like the Center for Internet Security‘s Docker benchmark and CoreOS‘s Clair, these kinda run a little too late in the pipeline for my liking. If we want to treat infrastructure as code then surely we ought to be performing code reviews and if we’re performing code reviews then perhaps we can perform a subset of these checks automatically pre-commit?

Many of the current generation of infrastructure orchestration tools utilise Domain Specific Languages presented through the medium of YAML, JSON etc which allow the infradev team to specify programmatically, the architecture and nature of the infrastructure they manage. Just how secure are these language and where might we find gaps that an offensive party might seek to exploit? In practice, what I was really thinking was, if I want to review commits (automatically), then what exactly do I want my tools to look for and why? This seems like an obvious question but at that point, I hadn’t seen a huge amount of talk (or more importantly, based on the work I do, evidence) on how others were doing this to review their templates before they’d been built and deployed….

The good news is that somewhere along the way, whilst I was still asking around and before I started to work on this series of posts, I discovered cfn_nag which looked like a great start, albeit only if you’re working on AWS‘s CloudFormation platform. Taking inspiration from this discovery, my next search was for a linting tool for Ansible (my preferred choice for infrastructure orchestration) and this too yielded results, namely ansible-lint. It turns out that there is more going on than I’d originally feared but that if you want to do this kind of thing (and you should), you really want to be looking for linting tools for your preferred templating language. One observation I’ll make however is that many of these linters don’t appear to have a regular stream of updates and that they may only support a limited set of checks.

In the next part of my thought experiment, we’ll take a deeper dive and I’ll start to consider just how effective these linters are, looking at both the theory of static analysis and code review as it applies to secure development more generally and just as importantly, looking at the assurance these tools can give you.

The post Use Infrastructure as Code they said. Easier to audit they said… (part 1) appeared first on Portcullis Labs.

]]>
https://labs.portcullis.co.uk/blog/use-infrastructure-as-code-they-said-easier-to-audit-they-said-part-1/feed/ 0