The post Security Engineering – A manifesto for defensive security appeared first on Portcullis Labs.
]]>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?
The post Security Engineering – A manifesto for defensive security appeared first on Portcullis Labs.
]]>The post Use Infrastructure as Code they said. Easier to audit they said… (part 1) appeared first on Portcullis Labs.
]]>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.
]]>