Individuals engaging in various work-related activities
With constant evolving threats, the challenges faced by cybersecurity professionals continue to escalate. While this is not new, the tooling in use and how the threat actors are shifting faster is a recent phenomenon. What can we do to meet demand and continue to provide the best security possible? The simple and most efficient answer is by using automation.
Standard practices still work and are required; manual inspection by a trained security engineer is equally needed. Many individuals face pushback or resistance dealing with the term automation; rest assured it is not to replace you but rather to enhance you.
Let’s take on one of the earliest security stages by looking into automating our threat modeling early on in a continuous delivery pipeline and providing autonomous updates to our threat model over time as systems change. For those who are reading, by change, we do mean by way of Change Request, which follows a strict policy.
How do we approach threat modeling with automation in mind?Great question! We’re glad you asked! A short but concise answer; We need to think outside the box and understand many frameworks available to enhance our automation efforts. With that said, something of immediate focus comes to mind Infrastructure as Code (IaC).
Working across teams such as leadership, DevOps, developers, and the list can grow. Another good time to point out how automation can aid you is freeing up your time to think of other brilliant ideas and further enhance the company’s security posture.
What benefit do we gain by performing automation in this area? Another great question! Automation allows us to perform manual inspections more often while making them more meaningful. We know there are plenty of scanners and tools outputting false positives, and with automation, we can fine-tune the designed system to operate more efficiently and remove the noise. It becomes more important to look at data overall when you know the noise is removed and looking at actionable threats remain. To recap, you’ll save lots of time and energy by automating a few tasks and using time and energy to reduce stress over missing a critical threat. We’re only human, after all.
The problem, let’s face it head-on. We are always presented with a problem and begin working on methods to solve the problem. Our problem today is how do we work with IaC to perform threat modeling continuously? We can focus on the data provided to us by our DevOps friends, and immediately, we have a few quick wins. We know what resources will be instantiated by infrastructure as code, and we can determine if new devices are added because we can now track drift in our threat models generated. Rogue devices beware!
A process emerges from the information we have so far. Let’s take a look at a sample of IaC structured from Terraform. Our goal is to understand what is required in code to create a resource. We will build our basis for simple automation from the information provided below, no need to make a complex system. We can build in small batches to enhance our automation over time.
The above snippet represents a very simplified file structure for Terraform. If you’re not familiar with Terraform, we highly recommend reading their documentation, and we’ll be using their documentation to represent resource structures.
The above snippet represents a resource in Terraform. Our intention with the block of code is to create a new ec2 instance by calling the “aws_instance” attribute, naming it “web”, and providing both the AMI and instance type to be used.
Data presented allows for some form of classification and will open pathways to explore automation. We have a resource statement followed by the type of instance and our naming convention for what we are creating. Within the braces, we have further details from which we can get more data from.
A structure for working with data from the Terraform code snippet. We can think about what we can do to work with the data now. Parsing the file, we would need to ignore blank lines without text, parse for the word resource, pulling the first argument in quotes followed by the second argument until the opening brace. From here, we would need to parse based on the equals sign and new line entry and finish up with the closing brace.
We have enough information to begin working on a proof of concept and our first steps into thinking about automation. Given the circumstances above, you’d be well equipped to take the next step into working with a scripting language to parse the content and assign values or pull in other resources to fill in information about what threats exist. Remember automation is meant to ease our workload so take a seat, buckle up, and welcome your new 24×7 on-call colleague.
User Journey is a pivotal customer engagement that must be tested by all team members to allow a complete and accurate picture. Our Human Experience (HX) approach seeks to build engaging and empowering digital services by elevating users in all aspects.
Softrams team is excited to join Health Level Seven International (HL7) as a Gold Member. HL7, a non-profit organization provides comprehensive guidelines for the exchange, integration, sharing, and retrieval of electronic health information.
The Centers for Medicare & Medicaid Services (CMS) awarded to Softrams, LLC a Task Order contract for the development of a modern Medicaid Drug Programs (MDP) suite of products. The Softrams team includes three subcontracting partners.