You can think of the ISM as a single document that helps Australian businesses and government know how to address cybersecurity challenges.  In reality, the ISM is really a collection of different guideline documents that focus on specific areas of IT.  Some of the existing guidelines address things like system hardening, database management, network management, using cryptography, and many others.  These guideline documents as an aggregate can be thought of as “the ISM” and can be used to increase an organization’s cybersecurity maturity which benefits both the organization itself, but also Australian society.

What’s in the Guidelines for Secure Development section of the Australian ISM?

In December of 2021, the ACSC released the latest version of the ISM which for the first time included a Guideline for Secure Development.  This document lays out a framework for building and maintaining secure software development processes.  It is a total of 21 controls and is more prescriptive than what we typically see from other frameworks like APRA.

You can find the Guidelines for Secure Development here: https://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-software-development

The format for this blog post

I wanted to write this blog post to help Australian orgs know about this new compliance requirement from the ACSC.  The new Guidelines for Secure Development document is split into two sections which we’ll address separately below.
Those two sections are:  Application development and web development.  

We’ll break both of those two sections down into their individual sub-sections and the controls that exist at each one of those stages. At the end, I talk about how you can assess and implement the controls in the ISM.

From this point on I’ll refer to the Guidelines for Secure Development as “GSD” for brevity’s sake.

Okay, let’s dig in!

Section 1: Application Development

This section of the GSD is applicable to all forms of software development including: client/server, web and mobile.  So special emphasis on this section should be placed on all assessments you make using the GSD.

Within this top level section there are 6 sub-sections:

• Development environments
• Secure software design
• Software bill of materials
• Secure programming practices
• Software testing
• Vulnerability disclosure program

Development, Testing, and Production Environments

Segregating development, testing, pre-production and production environments into discreet separate workspaces is one of the core security principles of secure software design.  This segmentation can limit accidental issues and malicious attacks from spreading from one environment to another.  Software engineers are limited to dev and testing environments so that bad code or third-party issues can’t be added to production directly.

Software Bill of Materials (SBOM)

This section only has one control and it’s all about SBOM.  SBOM stands for “Software Bill of Materials” and the reason that it’s so important is that it delivers something we never had had before:  a complete “recipe” of what is in an application.  An SBOM is a single source of truth for all software dependencies, frameworks, libraries, resources, and services that went into making a specific software solution.   Most definitions of SBOM agree on the above, but some go further and say that any known vulnerabilities and cloud-based services should also be included in the SBOM.  To me, this makes sense as an SBOM should be both an end-to-end description of the application, but also should list any deficiencies and liabilities.  If one of the components used to build an application has a known vulnerability, it should be codified in the SBOM.

Unfortunately, SBOM hasn’t delivered on its promise yet as very few organisations are actually creating SBOMs when they build software.  If you want to know more about SBOM please check out our blog post on them here:  https://securestack.com/sbom/

Even though there are only two controls here the description specifically calls out static analysis (SAST), dynamic analysis (DAST), web vulnerability scanning, and software composition (SCA) requirements.  It also calls out penetration testing and it also mentions “prior to their initial release and following any maintenance activities”.  To me, this sounds like automated tests during continuous integration and deployment (CI/CD). 

So that should really be 6 controls minimum.  I expect this to be fleshed out on the next version of the GSD.

Vulnerability Disclosure Program

There are actually four controls in this sub-section.  The first three are somewhat redundant switching the terms “policy”, “program” and “processes” which might confuse people.  Luckily the last control is straightforward and requires that orgs use a security.txt file to advertise their VDP information.

I think we can simplify this section in this way:

• Are security researchers able to come to your website and find how to contact you if they’ve found a security issue?
• Have you partnered with a platform to allow security researchers to bring security bugs they find to you?
• Do you have a set of documents that describe your security policies?  And can your employees find it?

Section 2: Web Application Development

This section of the GSD is applicable to applications available on the web that users interact with primarily via a web browser.  This section should be carefully following if you are building web apps.

Within this top level section there are 6 sub-sections:

• Open Web Application Security Project

• Web Application Frameworks

• Web Application Interactions

• Web Application Input Handling

• Web Application Output Encoding

• Web Browser-Based Security Controls

• Web Application Event Logging

Open Web Application Security Project

The OWASP is an organization that is trying to help encourage application security through its community and projects like Zed Attack Proxy (ZAP) and the purposefully vulnerable Juice Shop project.

This section has only one control and it explicitly states that orgs should be following the Application Security Verification Standard (ASVS) when building web applications.

Web Application Interactions

This section has one control and it’s pretty specific:  All web application content is offered exclusively using HTTPS.  That sounds pretty straightforward, right?

Unfortunately, enforcing encrypted HTTP traffic is more complicated than many people think and require multiple controls and functions to be aligned.  Engineers need to make sure that HTTP is redirecting to HTTPS, that HSTS is enabled and that SSL/TLS is terminated in a secure environment.

I wrote a blog post about enforcing HTTPS which you can read here: https://securestack.com/enforce-https/

Web Application Output Encoding

This section has one control which is:  Output encoding is performed on all output produced by web applications.  This is a necessary requirement as the use of un-encoded data can cause serious issues as special characters can be interpreted incorrectly by the web application.

Web application event logging

The final sub-section has two controls associated with it.  The first says that all access attempts and errors need to be logged.  The second, stipulates that all logs are stored centrally in another location.

Unfortunately, we see less web server and application logging than we used to.  In the era of the public cloud, many engineering teams misinterpret logging functions like AWS’s Cloudwatch and Cloudtrail which log events at the cloud layer, and NOT at the application layer.  To be very clear:  Enabling Cloudwatch and Cloudtrail are NOT effective application logging solutions.

How do we assess and implement these controls?

Okay, so now that we’ve laid out all 16 controls in the new Guidelines for Secure Development document, where do we go from here?   Well, part of the challenge of this new ISM document is that it spans across the whole software development lifecycle (SDLC).  It talks about things the developer needs to do (local software testing) and it talks about segregating deployment environments.   It talks about things that happen at the beginning of the lifeycycle, and things that happen at the end of the lifecycle.  It talks about how to build your web applications and it talks about how your customers should be protected while using that application in a browser.

How can SecureStack help you assess your ISM compliance?

The SecureStack platform can help you assess and quantify your ISM GSD compliance with our SaaS platform.  We help you integrate your source code platform, CI/CD processes, build environments and your public cloud providers, and we do it all in less than 5 minutes.

Thanks right!  You can see assess your entire software development lifecycle in less than 5 minutes with SecureStack.  Check out the video to the left to see how!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

Are you sick of filling out security questionnaires to meet some compliance or audit objectives?  Most of the software engineers we talk to that have to fill these pesky forms out hate the process.  Many of them say to us that they really want something that could automate responses to security questionnaires.

I had to fill out my first security questionnaire back in 2002. The questionnaire came in the form of a large Excel spreadsheet and I remember looking at it and thinking at the time, “Man, that’s a LOT of questions!!” I wondered how they would know if I was telling the truth or not? I could just put anything down and how would they know if I was being honest? Would they come onsite and audit us?

Fast forward to 2022. We still use spreadsheets for our security questionnaires. They pretty much ask the same questions they did 20 years ago, and they are still being used by the same people. It is a hallmark of #infosec that you get told to fill out the questionnaire and it’s just something we all do.

Here’s the thing:  Security questionnaires aren’t that good at determining risk

• Security questionnaires are lengthy and take a long time to fill out. The industry doesn’t trust them very much but continues to use them for lack of anything better. Only 14% of organizations surveyed said they are highly confident that security questionnaires represent true security profiles.
• Finding the right people to talk to and getting responses from them is a real challenge.  This is especially true if you are trying to ascertain compliance around software development processes and you need to talk to software engineers.  Engineers are busy delivering software and often actively hostile to the audit or compliance processes.  Software engineers will sometimes not respond to queries which leaves the party responsible for collecting the data in a lurch.
• Questionnaires are usually not very accurate. The person filling it out usually doesn’t have the answers and often makes up answers or guesses, neither of which help. When asked, most risk professionals admit they have very little confidence in security questionnaires.
• Security questionnaires are a single point-in-time snapshot. Even if somehow, the original data captured in the questionnaire was accurate, they don’t get updated which means that you can’t really trust them for very long.

Developers are usually not aligned with security or compliance objectives

As mentioned above, security questionnaires aren’t great at determining risk in normal circumstances, but it’s even harder when you are trying to audit your software development processes.  Gathering data from software engineers can be really tough.  They are often resistant, and sometimes downright hostile to the idea that their development processes need to meet some compliance requirements.

Software engineers’ metric of success is not usually security or compliance-related.  Instead, it’s how fast they can deliver new features.  So, this explains in part why developers are often so against security teams asking them questions about their security protocols.  

,

SecureStack automates responses to security questionnaires which saves your team time and money!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

The DevSecOps Playbook

SecureStack is committed to open-source projects, that’s the reason we recently open-sourced the “DevSecOps Playbook”.  This playbook, originally written by our CEO Paul McCarty, was an internal automation document that explained how to secure application environments.  Now, after a bit of a re-work, it’s a comprehensive step-by-step guide to implementing a DevSecOps practice for any organization.  So, we thought, why not share this with the world?!

Check out the GitHub project here: https://github.com/6mile/DevSecOps-Playbook

How to use this free open-source Playbook

The Playbook is 50 individual tasks that you can follow to help make your application environments materially better.  Each task has a Priority, which tells you what you should do first, as well as a Difficulty which tells you how hard that task is.  So your teams can start with all the priority 1 tasks and once they’ve crossed all those off the list, they can start with the priority 2 tasks.  It’s really that simple.

If you like the playbook, feel free to star it on GitHub, or fork it for internal use.  If you see something that needs adjusting or if the Playbook is missing something, please create a PR!  We want the Playbook to be a community document!  You can check out our community stargazers here.

If you have a compliance or audit requirement that you need to address, check out the last column in each controls row.  You will see there any mappings that our community has associated with that particular control.  Most tasks have been mapped to at least two frameworks, such as ISO27001, ISO27002, SOC2, CIS, APRA, NIST 800, Australian ISM/Essential 8, or PCI-DSS.

Accelerate your DevSecOps success with SecureStack

Because the Playbook started out as an internal piece of automation, it’s built right into the heart and soul of our solution.  The SecureStack platform will check your applications for all the controls listed on the DevSecOps Playbook and report back if it finds any missing.  Even better, our platform will help you understand how to address any gaps we find with our visibility and automation platform.   We give you real-time continuous compliance reporting on your applications, so you can meet ISO27001, ISO27002, SOC2, CIS, NIST 800, NIST SSDF, Australian ISM, or APRA requirements.  If you have a security questionnaire you need to fill out or are going through an audit and you’re being asked about how secure your software development processes are, then please reach out to us!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

SecureStack provides GitHub Actions that help you easily:

• Scan for secrets & credentials
• Scan for vulnerable third party libraries (SCA)
• Identify attack surface (ASM)
• Scan for web vulnerabilities

Check out our video to see how easy it is to get up and running with SecureStack!

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!

How can I make git more secure?

Git is super powerful.  We use git to interact with our most important intellectual property:  our source code.  For a SaaS provider this source code really is the whole business. If someone steals it, your IP is gone and so, probably too is your business.  So this begs the question:  How do you secure your use of git?

Git was originally written by Linus Torvalds to use for the development of the Linux kernel, and most engineers that use it only use like 1% of it:  git clones, pulls, pushes, checkouts, and commits.

I use git for many reasons now:  First, for the ability to automatically create a local (and centralized!) copy of what I’m working on (git commit, git push).  Second, for the ability to share my work with the team and let them iterate on the code themselves independently (git clone, git pull).  And finally, for the ability to fall back to an earlier version of a thing I was working on (git commit, git checkout).

My team of software engineers uses git every single day to build SecureStack products.  I also use git when I interact with open-source projects like MVSP or CycloneDX.   Part of the power of git is you can use it for basically anything:   source code, text files, binary files, zip files, DLLs, and a whole more.   But the real power of git is felt when an engineering team is building and collaborating together to create software.  It’s pretty amazing!

Unfortunately, git famously can be difficult when something goes wrong, or when you use it in a way that it wasn’t intended (like as a backup).  So there are definitely some gotchas that I learned along the way, that I am going to share with you now.  Enjoy!

8. Don’t use git as a backup!

I’ve seen a number of companies use git as a backup rather than as it was intended to be which is a concurrent versioning system.  What makes git really awesome is its ability to track changes across files and allow multiple developers to interact with those changes and that collaboration.  what git is not good at is backing up your mac or your Windows box.  There are other tools like Crashplan, Dropbox, or Google Drive to do exactly this.

Even worse than using git for something that it’s not good for is then leaving those backups as public repositories.  The amount of detail around your life and behaviors that criminals can find in these backups is huge.  Passwords, aliases, rc files, etc are all easily minable from backups like this.  My suggestion is you don’t use git in this way period, as its too easy to forget about it and therefore leaving yourself exposed.

7. Don’t store secrets in git repos

All developers have at some time thought it was perfectly acceptable to store credentials in a .env or config file.  It’s just something you do because no one tells you not to, and no one shows you a better way to do it.  And, to be fair it’s definitely a lot more complicated to use a secret store or key store to hold your sensitive credentials and application config details, than it is to simply put them in a local file and source that file.  But then at some point all developers will accidentally add that file to a gir repo and push to a centralized location and then the credentials go out with it and are distributed to everyone that pulls or looks at that code.  Then when the team finally notices and understands the problem, they have to go *fix* the problem!  That means changing the credentials (hopefully!) but beyond that it means that the team as a group has to do agree a solution and then follow through and use something like a secret store.

6. Upgrade your git!

Many developers using a mac don’t realize that the version of git they are using is probably old.  Most git installs on Apple devices come from the Xcode package and typically are two or more years old.  For example, until I installed git from brew I was using the most recent version of git via Xcode which was 2.24.3 which can out in late 2019!

You can find the most recent version of git at https://git-scm.com/download/

5. Create a .gitignore file

As you are working on code you will want to make sure that your changes are being tracked.  The first step in doing this is to use a git add . command.   When you use the period as a wildcard you add anything in the working directory to that git repository.  And this is where many engineers create problems for themselves, without even knowing it!  Perhaps you had a .env file in that local directory that included all the usernames and passwords and connection strings for your app.  When you do your git add . you are adding that .env file to the repository, or any other config files that include sensitive data in them.

And it’s not just about making sure that sensitive data doesn’t get committed to your repository, it’s also about saving space and lots of time.  As an example, when working with javascript code it’s really common to add the whole ./node_modules directory into the repository.  Same with the package-lock.json.  These files and directories are NOT necessary and don’t need to be included in the repo.  When you do a npm build or run yarn these files will get created at build time so you don’t have to add them.

Create a local .gitignore file and add the appropriate exclusions there. You can get a list of customized exclusions from https://github.com/github/gitignore

4. Use git hooks to automate tests

Most developers don’t realize that every git repo comes with a pre-configured set of git “hooks” that allow them to automate parts of their continuous integration workflows.  If you look in the .git/hooks/ directory of your git repo you’ll see 12 files by default.  Of those, the most powerful and best one to use for this purpose is the pre-commit git hook.  These git hooks are just scripts so you can drop bash commands right in.  Create a new file in that directory called “pre-commit”, make sure its got execute permissions and drop your security tests directly in!

You can read more in our blog post about git hooks here.

Many developers I’ve talked to about this problem push back saying that  you can’t get much with a git repo and to them I say, look what I found today:

DB_NAME=production
DB_USER=dbadmin
DB_PASSWORD=REDACTED
DB_HOST=ls-REDACTED.rds.amazonaws.com

That is a customer’s production database creds sitting in a .env file in their exposed .git directory.  I wonder what they could do with that?!

2. Use SSH keys to interact with repos

Most companies use their company email as the login to their source code management platform like GitHub or Bitbucket.  Then, to make it worse, most orgs don’t enforce using MFA or the use of SSH keys, so now all the bad guys have to do is phish your engineers and get their passwords and your crown jewels are now in the hands of criminals.  So, the easy fix is to enforce the use of MFA and/or SSH keys during login.  Why?  Because this verifies that the user is who they say they are with at least one additional factor of authentication.  I would suggest you use SSH AND MFA with something like Krypt.  Some organizations only require occasional multi factors, like every 30 days or similar, but to me, it makes sense to have the power of multiple factors with every push.

SecureStack provides security coverage across the whole of your SDLC

Our platform helps you protect your most valuable asset:  Your source code.

SecureStack is easy to use as it’s a SaaS-based platform so you can be up and running in less than 3 minutes with complete coverage.

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 Mentioned in KuppingerCole's Leadership Compass for Software Supply Chain Security!