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

Repost - are all proxies actually security assets?

Bear with me readers, in this article I posit a controversial viewpoint. That viewpoint is that all existing technologies acting as proxies to transit security zones must be considered a security asset and that the security team needs to get more involved in load balancer design and operations.

What are we doing with proxies these days?

Working in information security and on the technical side of things you often get involved with the use of reverse and forward network proxies to transit security zones often defined by firewall appliances.

A reverse proxy terminates the flow of data from untrusted networks in a semi-trusted network zone, your external De-Militarized Zone and fetches data from a more trusted network zone. Your reverse proxy is meant to have minimal functionality enabled and be security patched up to vendor recommendations. The whole idea behind the reverse proxy is that even if a vulnerability is exploited on it, at least it’s not in the core of your network with access to everything.

A forward proxy fetches information from an untrusted network and returns it to a user or a system in a trusted network zone. Sometimes in large enterprises you will have user proxies and application proxies. The user proxies fetch content from the internet on behalf of the user and work on allowed categories that users are permitted to retrieve content from, whilst the application proxies allow internal systems to integrate only with whitelisted URLs they are allowed to post/get data to/from. The forward proxies simplify firewall rules and routing and help protect users and systems from retrieving malware or “phoning home” to malware command and control systems.

Proxies also should be used to terminate flows of encrypted data so that they can be inspected for malicious payload. With a DMZ located reverse proxy often an external CA issued digital certificate is installed, connecting to an internal CA issued digital certificate on the internal system. Private keys for these internal certificates can be loaded into intrusion detection and prevention systems etc. Sometimes these proxies are chained to Web Application Firewalls. With forward proxies, user computers are configured to trust internal CA issued certificates, which the forward proxy uses to perform TLS inspection.

Other “proxy technology” can include application specific forward DNS servers and NTP servers.

Why do we do this?

Historically we have only had north south network segregation. Hence web server vulnerabilities would result in access to underlying operating system and shared network segments. With a DMZ if a web server is compromised, maybe all web servers end up being owned through lateral “pivoting”, but at least not the database servers.

Often the only reason we are running apache in a DMZ as a reverse proxy is “because security told us” or “that’s how we’ve always done it” or because that is usually how the vendor of the application commonly deploys it.

Developers would love to just run apache and tomcat on the same host, or heck just tomcat. Often Apache acting as a reverse proxy adds no application functionality, except for hosting a “sorry we’re down” static web page during maintenance outages. In many cases the web server in the DMZ is just hosting a “plugin” that fetches content from another web server on the application server.

How are things changing?

Load balancers also known as Application Delivery Controllers are able to perform TLS re-termination and act as reverse proxies. The main point of ingress into network zones is now the load balancer.

Cloud based user forward proxies are becoming more popular as they provide the ability to protect mobile workers with the same surveillance and security policy as on premise users.

Newer versions of TLS are likely to implement Perfect Forward Security (PFS) and the use of static encryption keys will be deprecated.

Slowly but surely East West Network segregation is coming in via the new buzzword in town Software Defined Networking (SDN). With SDN you can have virtual network setups for each key application and allow interactions with other key applications on principle of least privilege. East West segregation essentially turns every application into a “silo” and allows communications between them on principle of least privilege, restricting lateral movement by an attacker in datacentre networks. The days of physical network appliances physically wired to switches, routers and servers are numbered. The security market is moving more and more towards the build of reference models and QA review of deployment scripts which drive the build/secure configuration of application, server and network infrastructure.

Often proxy logs are being mined to identify malware command and control communications, as once the proxy is the sole method of communication with the internet for most users and systems, all malware communications go through it.

So what as a security team should we be doing?

The enterprise security function must take on responsibility for security policy on web servers that perform reverse proxy capabilities.

Enterprise security must take on responsibility for governing security policy implementation on application delivery controllers leveraging all native capabilities available such as TLS configuration, Layer 3 filtering, Layer 7 filtering, content inspection and identity and access management integration.

The security function must retain the responsibility for governance of security policy on forward proxies and tweak the policy to restrict the download of “dangerous file types” only from trusted web sites (e.g. only allow .exe downloads from trusted vendor websites) and look seriously at implementing user behaviour driven anomaly detection as well as sandboxing to detect malicious PDFs etc.

The security function must work with network architecture to see if the functions of tier 1 firewall, forward proxy and web server can be collapsed. Perhaps this can be accomplished with load balancers to simplify the network topology and allow us to deploy security policy in a single place? If a virtual load balancer can deliver secure layer 3 stateful firewalling capability, do we even need tier 1 firewalls in front of them?

The security function must plan to support newer versions of TLS which may implement perfect forward security whilst maintaining the ability to inspect web content coming into our DMZ.

Next Steps

Here’s a few suggestions I encourage you to take:

• Inventory the proxy technologies in your organisation and what SSL/TLS inspection is being performed.
• Investigate the native and optional security capabilities of load balancers, whether they are hardware appliances, virtual appliances or Amazon Elastic Load Balancers.
• Develop a strategy/roadmap for consolidation/simplification of reverse proxy capabilities and addressing the support of future versions of TLS with mandatory perfect forward security.
• Investigate the capabilities of your existing forward proxies and whether you are making the most of that investment.

Repost - ​Mossack Fonseca - Insider Threat - What would you do?

So with all the press related to the Panama Papers I began thinking again about insider threat. So here is a quick list of suggested actions specifically to tackle data leakage/whistleblowing/insider threat. This is a particularly difficult challenge in information security as you often need to provide access to all customer records to the lowest level of employees within the organisation to facilitate timely customer service processes.

1. Engage an organisation to provide an independent whistleblower call center and encrypted contact form service with investigation support for the organisation to provide employees with an alternative to going to the press in case of middle and even senior management misconduct. This is a fail safe measure to prevent corporate data sets being exfiltrated to the press by well meaning if misguided employees. This also provides an increased ability for prosecution of insider malicious actors who may claim whistleblower protections as legal cover for a failed data theft/sale.
2. Identify the most sensitive information in the organisation and the systems in which it resides. Check that access to this information is authenticated and logged ie. access to the content not just authentication success/failure.
3. Investigate to see if there is an easily identifiable identifier for each customer record. Investigate its construction. Even consider modifying its construction so it is based on an algorithm that can easily be checked in a Data Leakage Prevention system signature to minimise false positives.
4. Block unapproved file sharing, webmail and uncategorised websites in the corporate web proxy policy.
5. Provide an approved file transfer capability for ad-hoc file sharingwith business partners
6. Block USB storage device usage. Perhaps only allow the use of corporate issued encrypted USBs for the required edge use cases which enforce centralised logging of file activity.
7. Implement TLS inspection of web traffic and Data Leakage Prevention (DLP) on endpoint, web and email traffic including coverage of the approved file transfer capability (while you are at it ensure opportunistic TLS support in email gateways is enabled for data in transit email protection with your business partners)
8. Block the use of encrypted file attachments in outbound email in favour of the approved file transfer capability
9. Implement a network surveillance system with TLS inspection, alert, traffic replay and alert suppression whitelisting capabilities
10. Integrate DLP and network surveillance integrated into a workflowed case management system supported by a well resourced internal investigation and incident response function
11. Insert honeytoken records into each of the sensitive customer data repositories so that when they are accessed across a network, the network surveillance generates alerts for mandatory investigation.
12. Tune out the false positives from honeytoken alerts from regular batch file transfers between systems
13. Revisit all of the customer data repositories and ensure that only a subset of users are authorised to access file export capabilities
14. For key systems implement a privileged access management solution with surveillance of administrative access and workflowed tight integration with change and incident management approval for facilitation of timeboxed privileged access

Hope that gives you an insight into the complexities of tackling data leakage and insider threat. There are another two levels of detail under this plan required to execute this successfully through requirements, procurement, design build and run.

As always I am welcome to queries from fellow security professionals and interested executives.

Repost - From IT security to information security and beyond...

Over the years, yours truly has been heavily involved with the evolution of the modern “comuter security” function in a number of organisations. I thought it might benefit readers to receive a brief history lesson, take a current pulse check and look forward to the future of the evolution of the information security function.

In the 1990s the security function in an organisation was called “IT Security” and looked a little like this:

• The team had an asset centric focus, with a focus on deploying, maintaining and managing protective technologies including anti-virus software, web content management, firewalls and intrusion detection systems.
• Security products were typically ‘bolted on’ to technology environments to help mitigate underlying deficiencies and IT security teams were always looking for ‘silver bullets’ from security vendors to resolve security concerns or at least point at when a security breach occurred with a “hey we tried look we bought a widget that said it fixed that”
• IT security’s role involved saying ‘no’ to projects with little explanation or justification mostly because personnel had no idea of how to comply with policy.
• Organisations relied on a perimeter based approach to network security, with these perimeters typically being well defined due to physical security
• Security reported to the CIO for budget and the CIO often declined security team requests with a lack of budget being a number one concern for “security managers”

The modern information security practice of the early 2000s looks more like this:

• The focus is on data and a risk driven approach to securing it wherever it may be.
• A key activity is securing the expanded enterprise with corporate and customer data held by service providers 
• Many organisations are successfully preventing accidental data leakage by employees with signature based technology such as Data Leakage Prevention (DLP)
• Security is focused on saying yes to project teams and the business and making sure key building blocks are available for consumption such as typical deployment patterns and reference architectures with security built in with a “look here’s one we prepared earlier” attitude.
• The network perimeter has been expanded to encompass corporate mobile devices and corporate wireless systems
• More security controls are delivered is through the upper layers of the Open System Interconnect model with Web Application Firewall and Identity and Access Management products are being use to secure access to applications and databases
• Security controls are embedded in infrastructure builds through security engagement with SOE builds.
• Security is built in via security standards and process as part of the Software Development Life Cycle (SDLC) focusing on mitigating vulnerabilities
• The security team reports to the Board, keeps the CIO honest and often is well funded due to executive level concerns about brand damage and service interruption due to well publicized security breaches.

The future of the information security function might look like this:

• Increased service provider focus due to “cloud” focus with service provider selection and evaluation for a defined set of use cases for hosting as a key competency
• Security playing a key role in driving corporate strategy and providing constructive criticism in the area of cloud adoption especially in the fields of service orchestration and business continuity
• Extensive use of personal devices for corporate activities (phones. tablets, home PCs) for teleworking/mobileworking with a selection of security controls that balance security with user experience
• Widespread use of security services provided via the cloud such as: threat intelligence, web proxy and malware detection
• Full charge back models being deployed for use of security services direct to business units on a per employee or per customer basis, making the security function self funding.
• Malicious data leakage detection undertaken through extensive network and system data analytics
• Building and selecting secure systems through SDLC and procurement processes, with a focus on consistent key security control implementation
• Software defined networking and full virtualisation of the network
• Horizontal service based network segregation rather than vertical tiers
• Enabling developers to self assess the security of their code, libraries and dependencies to facilitate containerisation adoption, reduce time to market and eliminate environment inconsistencies.
• Security perhaps reports back to CIO whose role has evolved from IT asset management responsibility to data and service provider governance with alignment rather than opposition to information security objectives.