5 things to consider when you go “DevSecOps” security tool shopping
Disclaimer: All thoughts are my own. I do not represent any organization on this medium. (see what I did there ;) )
To summarize, here are 5 things I believe security teams should consider when they go shopping for a security tool in this “shift left” world. I learned this through my near 5 year experience working closely with large, small, centralized, diverse organizations for their security needs in cloud native world. So here’s my two cents —
Actions speak louder than words!
Loved the sales pitch from a cool security vendor and now you are all into it? Just pause and think again. Only this time, forget about the UI, the awesome presentation deck, the cool logo and everything they told you is important. Think practically. For your organization, for your specific needs, would the tool be giving your developers actionable data to work with? Remember they may not be sitting in front of the UI 24/7 admiring it’s brilliant colors. Recognize their needs, some questions I can think of are — does it have APIs for everything it says it does? Does it provide remediation details on how to fix stuff? Can it be easily integrated into the development pipelines?
Your scan worked! now what?
Let’s say you’ve got your ‘actionable data’ need in pocket. Now, how is it going to work at large scale? Would you need to keep an eye on it every 2 hours to look for red alert pop up? Not practical (Unless, you’ve really nailed the art of overworking). Two words — “Alert Integrations”. Find out what SIEM tool or ticketing system your DevOps team uses to assign tasks from security incidents. Then find out if the tool you are checking out supports it or plans to support it.
Whose pipeline is it anyway?
If you have many application owners and teams who follow their own deployment patterns and timelines, then this might be a rather important one to note. The top two points will make it easier to integrate and report, but it’s important that as a security team you have a single pane of glass view. After all, you can’t secure what you can’t see. Ability to easily identify and group reports from different teams/applications, to enforce policies from a central control, to provide granular access controls with limited visibility for application owners are some traits to look for.
“Merry Christmas!” said the Admin
Sometimes you may need more than just an alarm clock for security. Meaning, more than an alerting tool. Something that you can rely on when you are away celebrating Thanksgiving or Christmas with your family. It might be helpful to look for “Preventive” or “Blocking” measures in your tool so it can handle critical security incidents automatically without user intervention and pro-actively protect your environment.
Maintenance overload — Keep It Simple.. Silly
If you have to spend more time deploying and maintaining your security tool than your application itself, then something’s wrong. While this may not be the immediate thought while shopping for your tool, may still be a good idea to check how the tool is needed to be deployed. Also important from security perspective to know if it needs to be embedding binaries in your applications or so. The easier it can be deployed, upgraded or uninstalled, the more time you have to focus on actual implementation — Save those hours!
Ultimately, every organization’s needs are different. And the above pointers are meant to give a general direction on cloud native security. Good luck on your search! May you find the best tool that works for you.
