Are you into Security DIY?

Shortly after the RSA Conference, James K. Adamson captured my attention with this tweet:

Security DIY seems to be at an all time high, with many building what they need and eschewing the use of commercial tools #RSAC2016 — James Adamson (@jameskadamson) March 3, 2016

James K. Adamson (LinkedIn, @jameskadamson) is a Principal Consultant at Online Business Systems. As someone with experience that cuts across industries and includes a business mindset, we routinely engage online.

This tweet and the concept of Security DIY was interesting. Did it mean we were favoring only open-source tools and homemade code? Or was it the signal of something bigger. The resulting conversation put the last two decades in perspective, with a twist.

Here are the five questions with James K. Adamson on the importance of Security DIY:

The concept of Security DIY is intriguing. What does it mean?

The 140 character limitation probably drew me to that phrase, but I think it accurately describes what a growing number of security practitioners are doing. Consider the Home DIY analogy: Instead of buying new construction or hiring a contractor, the homeowner goes to a hardware store and buys the elements needed for the job. Combine that with research, experience and probably a little trial and error and they can do the job themselves. It’s not that a security team needs to write their own A/V or build their own crytpo algorithm (please don’t), but rather that specialized tools are being developed that can be used together to help build security solutions. Many of us come to IT and Security because we have that hacking mentality. We’re a bit lazy and if we can cobble something together that automates what we need, then it makes our lives easier.

What are some recent examples of Security DIY?

Cloud and DevOps is certainly on the forefront of this movement. Companies that are early adopters have had to find their own solutions for the new architecture, and many times this meant coding or scripting. So you have companies like Netflix who are developing tools and then publishing the code on github (https://netflix.github.io) for other teams to adapt and adopt. Security teams can benefit from taking advantage of the new platform and the new mindset.

Why wait for a vendor to develop a solution when you can use a few existing apps and an API? Container services paired with automation and orchestration scripts can run a vulnerability scan against any new instance immediately to identify issues prior to promotion and potentially even identify the fix. In AWS, combine CloudTrail, Lambda, and a few storage buckets with some code and you have customizable event alerting system. In both examples you can easily see the power of automation in providing repeatable actions that result in more consistent security. More than a few talks in the cloud and virtualization track at the recent RSAConference had real-world examples of these types of Security DIY projects.

Why do you think Security DIY is on the rise? What factors and advances in the industry make this possible?

There’s been a large swing over the last few years where the pendulum is heading back from distributed computing to centralized platforms. The architects of many of these new platforms have thankfully decided that customization and extensibility serves their consumers well. APIs and microservices are being provided, even encouraged, for customer use and development. With startups on the rise looking for cheap and powerful solutions to fit any need, this has spurred adoption.

Additionally, these platform are early in the maturity cycle. Product immaturity drives people to build their own solutions. Competition will creep up around solutions to the most common problem sets. This will lead to many of the solutions being commercialized and then, eventually, some will be assimilated into a product aiming to serve the rest of the security market. I think it’s likely that this echoes the rapid development pace of the cloud platforms.

What are some of the pros and cons security leaders need to consider and prepare for?

Security DIY allows for the customized delivery of security in a developing ecosystem, potentially ahead of your competitors. You get exactly what you need and now have an alternative to waiting for vendors to develop a solution. This can allow you to improve internal security measures and provide added value for your customers.

Most organizations do not likely have this knowledge in house at the moment. So they will either need to develop (slow) or hire (expensive). Security professionals are hard enough to come by; finding one who can develop custom security solutions for your environment is going to require a close look at the budget. This type of development is also not listed in most security department’s job responsibilities. It’s exactly what security services and product vendors do every day.

This may also lead to a familiar conversations around open source vs COTS products. Every pro (customized, flexible, inexpensive to purchase) has a con (buggy, unstable, expensive to maintain). For example, if your solution uses services that another organization wrote and maintains, and they decide to change strategic directions (i.e., study bankruptcy regulations), you may find yourself trying to re-architect the solution on short notice.

Ultimately security leaders need to determine what is necessary to secure their environment to meet their organization's risk management tolerance. Especially in cloud environments, the threats will be advancing and changing at a rapid pace which will require the flexibility of Security DIY. Defining the proper responses for threats or vulnerabilities and coding the reaction will be a huge growing curve from today’s security mindset.

What can a security leader do to test it out for themselves?

Thankfully, the internet has made the learning curve much shorter. Udemy or Code Academy are a good way to learn programming. Python is a commonly recommended beginner language that is being used to script security solutions. Even just familiarity can help you understand what code is doing. If you’re more on the governance or risk side, you might want to learn R and start doing real data analysis to determine your risks more accurately.

AWS actually offers a year(!) of free access and allows a surprising amount of it’s services to run free in that tier. Go sign up and learn how they work. Review their Reference Architectures or use a Quick Start and build a simple environment. Then grab a few of the tools from github and see if you can use them to protect your new environment.