Repost from 2009 - what do you need to know to work in infosec?

 Here's a list of things that are really handy to know for the day to day business of information security. Note, if you know how to do these things then learning to review them is simply applying "audit methodology". Hope this list will be useful for myself as a refresher and to others wanting to further their skills:

1. TCP/IP basics like OSI model, routing, protocols, ports, NAT
2. Construct a checkpoint firewall rule base
3. Construct a PIX firewall rule set
4. Configure a cisco router to CIS benchmark
5. Configure VLANs and port mirroring on a cisco switch
6. Deploy Microsoft security templates to a group policy object
7. Configure a WSUS server and run MBSA to check it is working
8. Use Solaris Security Toolkit
9. Administer a linux box, enable/disable services, use package managers etc.
10. Install oracle and mysql
11. Be able to construct an SQL query or two
12. Configure a web server or two (say apache and IIS)
13. Configure an application server or three (say tomcat, websphere application server, maybe BEA weblogic)
14. Be able to use a web proxy (burp, webscarab) and a fuzzer
15. Know how the following security controls of authentication, session management, input validation and authorisation are implemented securely for a number of application development frameworks
16. Configure an IDS or three (Snort, IBM solution set)
17. Know the ten domains in ISO27002 and their content
18. Be able to identify control gaps from ISO27002 in your operations
19. Be able to build a security plan to address control gaps (planned end state, costs and benefits, dates, actions and responsibilities)

RePost from 2008 - First jobs

 I was thinking about my first job in security, and was kind of thankful for the opportunity. I was a security guard at a police HQ on the night shift and the criminal investigation branch during the day.

Man, I had some interesting encounters with the general public, well the very sketchy portions of the general public.

It was kind of cool to roll in unmarked police cars on occasion and tote some sort of police ID. The responsibility sort of gave me some direction when I needed it.

Thanks for giving me the opportunity, you know who you are!

DevSecOps

Hey there internet people! It's me your friendly non standard non scary security architect.

I did a discussion at CISO Brisbane the other day which was a bit of a primer on DevSecOps.

So from my notes this is a blog post.

Let's stack some concepts and some history and introduce you to some cool people.

What's DevSecOps?

It's a portmanteau of Developers Security and Operations.  Three types of subject matter experts working together in a holistic manner in a spirit of collaboration and incremental improvement supported by the practice of platform engineering supported by a paved road providing a way for developers to deploy code incrementally at increased velocity in a low risk manner into production.

Why is it so interesting?

Everyone wants to go faster with higher quality and deliver features quicker for better services for their "customers". This is particularly interesting in the area of delivering enterprise software via the Software as a Service business model. If you can't deliver great software quickly you lose market share! It's also interesting in any organisation that provides services electronically to their stakeholders and business partners.

Agile - Perhaps this i where it all kicked off?

Agile development ( you know post it notes, kanban cards, user stories, backlogs and such) broke down the barriers between the business and developers and testers by using "plain english" user stories delivered in two week sprints to ship features that the customers wanted. Rather than taking years to deliver software and when it was delivered it wasn't what the customers wanted via the waterfall approach to software development.

DevOps - This is when it accelerated?

Gene Kim coined the three ways of DevOps being:

• The First Way: Flow/Systems Thinking
• The Second Way: Amplify Feedback Loops
• The Third Way: Culture of Continual Experimentation and Learning

DevOps broke down the barriers between developers and operations. The devs became parts of squads and got put on the pagerduty roster too! Instead of throwing software over the fence, the DevOps squad became accountable and responsible for overall quality of the applications. Concepts such as "observability" and building it into the software so it could be more easily supported were matured.

"security is a quality attribute" - Matthew Hackling 2012

Continuous Integration and Continuous Deployment

CI/CD was a concept that leveraged automation to deliver incremental low risk changes to production, with version control, unit testing, smoke testing, roll back etc.

Infrastructure as Code, Cloud and GitOps

With the wide scale adoption of public cloud by organisations that was API enabled for the deployment of infrastructure. Infrastructure as Code (IaC) became a widespread practice. This was further refined with the practice of GitOps where a source code repo using the Git version management system was utilised to hold the configuration state of infrastructure which was then deployed via the CI/CD pipeline to configure the infrastructure to a known state. There is the possibility of also validating installation to that state and performing "configuration drift management"on an ongoing basis.

"It's a small world unless you have to clean it" Matthew Hackling 2014

The Spotify Model

Now working in agile at scale the spotify model was pioneered. This gave an organisation the way to organise DevOps squads together using concepts such as tribes ( e.g. mobile, desktop etc.) , chapters (e.g. front end engineers, back end engineers) and guilds (e.g. security, test automation etc.)

Netflix and Platform Engineering

Now netflix pioneered the approach of platform engineering from their business unit which is/was called platform engineering and their excellent technical blogs.

The platform engineering approach was to provide squads with a "paved road" with guardrails to provide a way to deploy code into production onto a container to run a microservice etc. etc.

You could go off the paved road on an adventure or an excursion but when you came back you had to share all the learnings to improve the paved road and meet all the requirements of the enterprise paved road. Maybe you discovered a better way through the mountains of software development at scale?

The DevSecOps manifesto.

I think shannon lietz from sony/intuit ( what a legend) crafted this and hosted it on https://www.devsecops.org It's worth a read as it captures the vibe. The vibe is security is going to lean in and get data driven and leverage automation and stop being annoying and be part of the solution.

DevSecOps at scale

Practitioners such as Larry Maccherone pioneers DevSecOps at scale in entertainment and technology giant Comcast and captured a lot of learnings in documents.

DevSecOps in the military and Continuous Authority to Operate

The USAF led an initiative in the US Department of Defence to deliver a "software factory" to enable defense contractors to rapidly iterate software leveraging container technology and security automation without manual paper based process. I do believe there are now warplanes running kubernetes and software developed through this software factory.

Parallel Security Analytics Pipeline

Pioneered by Tanya Janca the concept of a PSAP is to have an independent slow pipeline that runs nightly with all the checks on to inform the platform engineering team about what checks, blocks and solutions to develop and implement in the main "paved road".

DevSecOps in major products/services that enable you to make software

Github, Gitlab and Azure DevOps all now have native pre-engineered devsecops tooling that is provided as "premium licensing" as part of their services. These provide:

• Software Composition Analysis  (Dependabot coming soon) - big win don't use vulnerable or back doored dependencies to build you apps and avoid Supply Chain attacks
• Secrets Scanning and blocking - prevent hard coded secrets from getting into your repo - you can assume a threat actor has access to it with the assume breach mantra.
• Static Application Security Testing (SAST) - run scans for common app sec problems with semgrep or codeQL rules
• IAC scanning 

Large Language Models

Microsoft has pioneered the use of LLMs to provide security education, code review of the open code in front of you, security coaching, writing static analysis rules in codeql with GitHub CoPilot X.

So here's a few points

DevSecOps isn't:

1. Running scripts under user credentials with elevated rights against an API, hopefully the right script
2. Just buying security tooling and putting it in the pipeline
3. Throwing PDFs or jira cards to developers with unactionable information expecting them to solve it
4. Tools that run for hours that developers just bypass or turn off to get their work done
5. RASIC charts and fights over gaps in the operational model
6. Checklists and spreadsheets
7. Security is someone else's problem
8. Painting the sydney harbour bridge with security vulnerabilities - when you think you have finished you have to start again
9. You are on your own and Goddess help you

What DevSecOps is:

1. Taking a platform engineering approach to make a paved road- with the easy way being the secure way
2. Coding out whole classes of vulnerabilities and preventing them coming back
3. Living the three ways of DevOps with incremental security improvements on the day to day
4. Developer empathy - don't give a developer a problem without a solution and put the solution in their context
5. Radical accountability for quality - security is a responsibility of everyone, everyone in the squad cross trains so they can do the basics of development, testing, deployment and production support. 
6. A "you build it you run it" attitude from the squad
7. You have support from champions, the security guild and the platform engineering team.

Gene Kim coined the three