Cybersecurity Program Coaching

 Every institution should have an ongoing

hashtag#cybersecurity program.

Technology changes, the way we use technology changes, threat actor behaviour changes, systems and services go out of support and compliance requirements change.

For example in federal government in Australia the Information Security Manual is updated on a quarterly cadence and material changes are made to controls and coverage requirements.

The expectation has been set that you need to be running contemporary technology configured to industry standards run with best practices.

You cannot be expecting that operational personnel do more than incremental process and technology improvement.

Cybersecurity is not a “solved problem” like say “fire” with fire detection suppression EWIS, drills, mature standards, fire fighting and ubiquitous reliable insurance cover. It requires constant adjustment to get it right for the organisation.

A well running program will be:

1. Regularly delivering risk reduction outcomes on at least a twice a year cadence.
2. Have “non-lumpy” spend and a three year commitment from management on ongoing budget and hopefully a slight downward trend in spend
3. Have a tactical stream of work to execute on opportunities to reduce risk arising from audit issues, observations and changes to technology
4. Have one to three strategic streams of work potentially aligned with security transformation to help the cyber team deliver more effectively or delivering risk reduction in a known control domain or an outcome to enable the organisation in a non security manner
5. Running a planning session well prior to the beginning of the calendar year to develop candidate work packages for prioritisation by the steering committee
6. Aligned with the organisation’s overall and IT work cadence so that change management considerations do not derail regular delivery outcomes
7. Give project managers a “project on a page” document with scope and outcomes to enable them to develop a more detailed project scoping document with their team
8. Run a risk register with primarily delivery related risks to be actively managed so that delivery does not “stall on a known speed bump”
9. Be advertising and promoting the program with a “catch phrase” an “elevator pitch” for each stream of work and collateral describing the program and its successes on an intranet page.
10. Have a register of key stakeholders and schedule regular contact between the right people in the program and them
11. Consider external stakeholder impact from each project and stream of delivery and “batch request” information and activities on a program wide basis so key stakeholders are not bombarded with agenda less meeting requests

Security coaching for non profit organisations

 When smaller organisations don't know where to start with

hashtag#cybersecurity they generally have these options available from the market:

1. Get a pen test done and do technical fixes as recommended on critical issues. Surprise - its probably patching and secure configuration aspects
2. Do a desktop based assessment performed to a selected standard and do critical fixes as recommended. Surprise - its probably creating or updating some policies
3. Technical training of their IT team so they have a clue. Surprise - it's probably funding self study and certifications.
4. Security awareness training of their personnel so they know what modern scams and digitally enabled fraud looks like. Suprise - it's probably non engaging elearning.

Unfortunately none of these immediately helps them provide a lasting step change in their cybersecurity risk posture or set them on the path to continuous improvement. Here are a few paths forward that might not have come to mind:

If you are a small organisation and have a decent attack surface to protect to look at procuring a capable attack surface management service which will provide you with continuous discovery and vulnerability scanning of your brand's digital assets and alerts on exposure outside of your risk tolerance. (These systems "feed themselves" and provide you with many of the benefits of an annual penetration test every day)

Consider looking at aligning your operations with "common sense" IT hygiene and security standards starting with offline or immutable tested backups, keeping your operating systems and applications in support and applying patches on a routine. Have a look at the CCMLite https://cloudsecurityalliance.org/research/ccm-lite which is mapped to many common security frameworks and has controls that any organisation can and should adopt and it comes with implementation guidance.

Look at a whether a Managed Detection & Response service fits within your risk profile and budget envelope so you have a chance to detect and eject attackers from your endpoints who don't work business hours and have day jobs to do like your IT team.

Look at what security features are available to you at low/no cost/big risk reduction benefit to implement in your systems. If you have EntraID (who doesn't due to M365?) you have the ability to implement phishing resistant MFA for example.

If you are operating in the hashtag#nonprofit sector and just not getting the love from the large cybersecurity consultancies and just don't have the budget to attract IT talent reach out for hashtag#itsecurity coaching that will help you get on the path to continuous improvement.

How to fix Mitre D3fend?

Praise

Mitre Att&ck framework has been a real game changer for detection engineering and for my friends in the Security Operations Center!

First big benefit is that it allows defenders to rapidly parse and understand threat intelligence as it's in a known pre-understood format! Threat intelligence not leveraging Mitre Att&ck framework is just plain annoying to read.

New TTPs can be added without messing up the "attack chain" format. These TTP "abuse cases" can be mapped to "use cases" or playbooks in the SOC.

Att&ck is very useful for SOC teams responding to security incidents resultant from control gaps or control failures especially leveraging Endpoint Detection & Response/XDR and Security Information Event Management technologies.

The desire for improvement

Now about D3fend, wouldn't it be great to have a similar extensible frame of reference for security architects who are building in defense in depth and attack chain disruption that we could use internationally, between clients etc.

The challenges

1. We operate in a microsoft monoculture. What institutions and enterprises do not utilise entraID, Microsoft365 and Windows 11 for their end user productivity environment? How to avoid this being a microsoft best practices summary?

2. A lot of security for this monoculture is delivered via bolt on third party security products or now optional microsoft security products. How to be vendor neutral? I have a personal preference for "OS native endpoint security"

3. This environment is not secure by default due to the desire by microsoft to support backwards compatibility "out of the box". Resulting in whacky scenarios where we are deploying "deception technology" to protect legacy identity technology.

4. COTS vs in house developed applications - Maybe we don't dive into secure application development in the SDLC, DevSecOps and the like in this model.

5. Vulnerability Management - let's exclude technologies that help us identify root causes

Key controls

Thank goodness that there are certain key controls that are partially effective against a number of "abuse cases"

These are:

1. Reducing root causes:

a) Patching Applications on Endpoint and Servers

b) Patching Operating Systems on Endpoint and Servers

c) Removing tech and security debt in IDAM - kill your Active Directory!

d) Patching Network Appliances

2. Protective Technologies

a) Secure Email Gateway

b) Secure Web Gateway

c) Application Control

d) Antimalware

e) Secrets management and secrets scanning delivering enforcement of their use

f) Cloud Identity & Access Management - that establishes a perimeter in public cloud hosting - governed by Cloud Infrastructure Entitlement Management (CIEM) capability in a CNAPP

g) Software Composition Analysis - detect and prevent known bad supply chain attacks

3.Technologies that prevent attacker lateral movement and app access after they get a foothold on an endpoint or a DMZ hosted system or in the bowels of an database via SQL injection.

a) IDaaS with Multi Factor Authentication and Conditional Access -Zero Trust Policy Enforcement Point

b) Zero Trust Network Access (because VPN appliances suck and identity driven access to network attack surface is very powerful esp. if implemented per application leveraging Identity Governance & Administration technology)

c) Macrosegmentation and Next Generation Firewall

d) Microsegmentation

4. Detective Technologies

a) Endpoint Detection & Response and XDR

b) SIEM and SOAR and EUBA

Abuse cases

We want to illustrate the attack chain disruption possible with these key controls across a set of abuse cases or attack chains:

1. Phishing email with link or attachment

2. Exploit of known vulnerability in an internet facing network appliance - eek - what controls apart from patching help with this!

3. Exploit of known vulnerability in COTS software

4. Supply Chain attack with phone home to C&C infrastructure

5. Stolen/leaked creds against API

Proposed working model for improvement

Abuse Case	Root Cause Remediation	Protective Technologies	Lateral Deeper Movement Prevention	Detective Technologies
Phishing Link in Email to actions on objective	N/A	Secure Email Gateway - Known Bad Sender Secure Email Gateway - Known Bad link Secure Email Gateway - Sandbox Secure Web Gateway - Known Bad URL Secure Web Gateway - Sandbox
N/A	N/A
Malware attachment in Email to actions on objective	Patch Endpoint Operating System Patch End User apps on Operating System	Secure Email Gateway - Sandbox	N/A	N/A
Exploit on internet facing appliance to actions on objective	Patch VPN Appliance or Use Auto Patch ZNTA	?	?	Logs?
Supply Chain Attack	Y	Secure Web Gateway - least privilege internet access for workload identities Software Composition Analysis - block known bad update to cached repo Software Composition Analysis - antimalware scan of repo	N/A	N/A

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 

 

What is a Parallel Security Analytics Pipeline

 

This concept was introduced to me by Tanya Janca now of https://wehackpurple.com/ at 2018 at RSA San Francisco.

What do we want to enable our developers with as appsec professionals?

D1. Coaching in the IDE with click to fix guidance for common organisation specific security controls - don't give a dev a problem without a solution

D2. High Signal low noise helpful LOW FRICTION cybersecurity controls in the Continuous Integration and Continuous Deployment pipeline that run fast on every build 

What do we need as appsec professionals in order to make this happen?

A1 - analytics - how big is the code base? have we got coverage of it? Have we got visibility of all the repos ? have we got visibility of the changes in the code base?

A2 - security analytics - what potential security vulnerabilities are in the code base?

A3 - process to triage and work through the backlog of potential vulnerabilities to find the flaws that really make a material impact to the security posture of the application

A solution to this is:

- linting in the IDE for the top 5 to top 10 organisation specific flaws with click to fix remediation

- quality assured organisation specific small accurate checks in the CI/CD pipeline that run every build that run fast in less than 2 minutes. If it's fast high signal and low noise the developers won't need to find a way around it

- a parrallel security analytics pipeline that uses SAST technology/s to scan ALL the code in the repos on a less frequent basis (say nightly or weekly) that takes multiple minutes to hours to run.

- a backlog of triaged potential issues to work through from the parallel security analytics pipeline output to confirm and to build the click to fix linting and main pipeline burn down to block checks

I propose we add onto this concept all the slow but good and full of false positive stuff like:

• dynamic scanning of APIs for unauthenticated endpoints and IDORs
• fuzzing