2024 UPDATE
The original project has been deprecated. The NZ Transport Agency pulled the origin project from GitHub and breaking changes in SilverStripe 5.0's GraphQL interface basically killed the SDLT. An alternative project has been developed named Odin. A copy of the original SDLT project is still available on my Github.
As a consequence, I have updated this blog post. Everything that mentions SDLT is directly applicable to Odin, except for the fact that we built SDLT in SilverStripe and Odin in Laravel.
Copying and evolving
At the end of 2018 I attended Kiwicon and a talk from Slack about the goSDL Security Development Tool. This was an interesting talk as I enjoy automating tasks where I can increase the return on investment. The goSDL provided an automated pathway through the security assurance process for internal slack developers. Coincidentally, the following Monday I was approached by one of our engineering managers to automate security assurance practices into their devops processes better. They were doing not adhering to the organisational processes and doing their own thing due to the ambiguity and complexity of the process. Aha! I thought, the Slack SDL could solve this.
24 hours later and we had a working copy of the goSDL running internally, but it didn't really offer the functionality we needed. The goSDL provided some check-lists, but they were really aimed at assessing a single product through a largely static process. We had >1,600 systems. It was very rudimentary and required quite a lot of knowledge on the part of the submitter to complete. While it did provide a risk rating, it didn't provide any context or next steps. We determined that we'd struggle to gain value from it, but we really liked the concept.
Following discussions with the Head of Security and a few weeks of me expanding on the concept with my own proof of concept I had a demo of what I had nicknamed the SDLT or Security Development Life-cycle Tool. The user could pick from different deliverable types and then get assigned tasks relevant to their delivery. Everything was handled in this simple web-app. The feedback was positive and the organisation offered to fund a version 1.0 release.
Note: Funny enough, a member of the devops team thought the proof of concept was a real product and made an actual submission for a change he was working on, so that was definitely something that helped get further funding.
Building and selling the concept
In my mind, I wanted to have a customisable work-flow system for our security assurance life-cycle. I researched and reached out to some vendors to see what was in the market, but the same four problems always came up.
- The licencing costs would be like $500k/pa
- The product didn't come with any default work-flows, we'd have to customise our own
- They had broken risk assessment concepts
- They required programming or scripting
This didn't sit well with me. Why would I pay $500k/pa only to have to build all the logic I wanted. Why can't I have something that is effectively drag-n-drop with simple customisations. I really wanted something that allowed me to build simple representations of flow-charts. Some of them talked about their alignment to the New Zealand Information Security Manual (NZISM), but when we asked for more information they provided simple control lists that weren't part of a wider process. Nobody provided an out of the box, easily customisable end-to-end assurance life-cycle.
I had some further discussions with the Head of Security and we decided to bite the bullet and take the funding to build our own version. Surely if we built something useful for us, it'd be useful for other organisations? So why not open source it? We're a public sector organisation, so there is no benefit in keeping it closed source. After some tough discussions with our procurement team, I was able to get a contract sorted that ensured the product would remain open source under the BSD licence following NZ Inc best practices. The organisation would pay a retainer to a local development company to manage the project for us. A total win win.
I reached out to contacts I had at Catalyst NZ Ltd who an open source development specialist organisation to see if they'd be interested in coming on board as our development partner; they jumped at the chance. We would be the first NZ Government Agency to fund an open source project. I wanted to take it a step forward and got approval to open source our own internal flows and configurations. This means that anyone who picked up the SDLT would be able to start with our working flows as a base and improve from there.
What the hell am I building?
I want something that is like a flow chart. The user would see a set of questions on the front end, and we'd have some basic logic on the back end to only show relevant things. Right, time for some key principles.
- Shortest Path First - The user only sees questions that are relevant.
- Only what is needed - Only give the user tasks that are necessary.
- Reduce the noise - Minmise the user of security team members in the process.
- 80% Hands off - 80% of all submissions shouldn't require any security team engagement.
- Conquer the world - Start with security, but rope in other teams and stakeholders with tasks
These seem like a good place to start. My concept was a security assurance work-flow tool that would handle >80% of all deliveries without requiring a dedicated security resource. We'd handle our obligations under the Privacy Act, Public Records Act and Official Information Act through the tool. We'd support different deliverable types including proof of concept, software trial, software as a service onboarding, project release, technical change and bug fixes. We'd deliver this as a Software as a Service web application.
The product would be open source, free for everyone and we'd provide our own internal configuration (flows/tasks etc) for nothing.
What is the Security Development Life-cycle Tool?
The SDLT is a web application that walks a user through the security assurance life-cycle. They're taken step-by-step through all of the required tasks and engages key stakeholders through a single platform. Where the deliverable has Privacy concerns, they'll be taken through a Privacy Threshold Assessment task that is automatically emailed to the Privacy Officers for approval. Approvals on all tasks and the submission are handled within the tool; no more printing/signing and scanning documents.
The SDLT provides a single front door to Security (and more... see below) for the organisation. The process is objective, repeatable, auditable and optimised.
Note: I say front door to security, but the reality is that we've also incorporated PCI-DSS, Privacy and Information Management as key stakeholders with their own tasks. At the time I departed the organisation work was underway to onboard procurement, legal and vendor services as well effectively making it a single front door to "go-live"
The high level user flow
The user would land on the front page and select the type of deliverable that they had. We bunched them into 4 categories that we call pillars.
- Proof of Concept or Software Trial
- Software as a Service
- Solution/Project Delivery or Initial Software Release
- Technical Change, Feature Release or Bug-Fix
After selecting the deliverable type, they'd go into the pillar questionnaire. The pillar questionnaire would ask key information about the deliverable. Who is the business owner? Will you deal with any personal information? Will you be exposing any new public services? When is your go live? Depending on how the user answers, the submission would have tasks assigned for the user to complete prior to submiting it for approval. If the user answers yes to personal information, then they have to do a Privacy Threshold Assessment. If they answer yes to exposing new public services, then they have to do a penetration test. Out of the box, we have approximately 30 tasks.
Tasks are broken down into 2 major types.
- Where the task is completed externally. We provide a link to the user from the SDLT task to the document they must complete. Then we ask for a link to where they have stored the completed document in our document management system.
- The task is completed entirely within the SDLT. We ask for information from the user and the tool determines the next steps.
Once a user has completed all assigned tasks, they can send the submission through for approval. The submission would be sent to the Security Architect team to review and approve. After a Security Architect has approved, the submission will be sent to the Chief Information Security Officer for a recommendation approval and to the Business Owner to formally approve and accept the associated risks.
Doing it without programming
The SDLT is designed to be edited by people without development skills. We use SilverStripe as a CMS and everything is built on top of that. When adding a button to a question you can create an action to assign. The button can give the user a message, skip ahead to another question or allocate a task to be created on the submission.
For more information about the different types of tasks we provide out of the box please check out the documentation.
Success or failure?
The SDLT was built on the crazy idea of building an open source work-flow tool for automating security assurance. Nothing in the market did what we wanted out of the box and those that provided frameworks wanted to be paid in kilograms of gold.
Two years on, we've had more than 400 submissions. Four years on we had 1,000 submissions through the SDLT. Over 75% of those would never have been seen by the security team due to lack of resourcing and process. Our primary focus had been increasing adoption so that we can increase visibility. We believe this has been incredible successful.
For those who noticed, above I noted that off the shelf products had terrible risk assessment concepts. We went on to build SDLT version 2 that includes a digital security risk assessment methodology. As this is a topic in it's own right, I'll write about this at some point. For those who are too keen to wait to hear more about this please check out the documentation. The TLDR is that we can automate the risk assessment process from start to finish and have it meaningful and measurable over time.
How do I get it?
The SDLT is no longer supported.
Odin is open source, you can grab a copy from the GitHub Repository and follow the documentation to deploy.
Free screenshots
If you just want to see what it looks like, here are some handy screenshots.
The SDLT Landing Page:
Answering questions within a pillar:
The summary screen listing tasks to be completed:
An example task questionnaire with a result:
