In one of my previous articles, I outlined the considerations to select a tool for enterprise-grade businesses. Most often the tech guys come up with the functional requirements. But it’s more than that. Business representatives as well as (senior) managers and personnel from legal and compliance departments have a say in it. Business professionals which are involved often demand (process-related) requirements and other not-so-common features that tech guys might not include in their list. Security tools: what business professionals want.
Context
The context of this article is the functional and non-functional requirements for a security-related tool that help DevSecOps teams find and fix vulnerabilities and other security misconfigurations. They all come from different websites and other sources which are focused on tool comparison and peer reviews. Therefore, it can never be truly objective. Instead, use the contents of this article to widen your (business) horizon during your tool selection and/or evaluation processes.
Handling all the features
Some tools have so many features that all scream for attention or on top of the menus that make up the GUI. User interfaces are so busy with menus, notifications, popups, breakout boxes, and other windows that it’s hard to get focus. This all applies to the number of integration points as well. In short, developers require an intuitive interface (opinions vary over what intuitive really is) but also (video) tutorials, podcasts, and actual presentations on how things are done. It’s not enough to just point to the documentation pages and let the user figure it out themselves. It would be good to have a special section for “new teams” to easily set up the most used features. Ideally, the instructions follow a typical developer workflow from source code to a running application.
License costs
Does every business professional want to find the ultimate answer to “what does it cost”? Most (cloud-native) tools do not have a very predictable price model. This all has to do with the ever-changing infrastructure and application landscape with which they interact with. It would be very beneficial to have some sort of future growth and predict the license cost based on that. Many companies do not know how many workloads (in hosts, containers, or serverless) they have (in different environments) let alone what the costs would be once they scale up and down every now and then.
To make things even more complicated: a license fee that is charged “per node” is pretty common. But how would you measure this if you can only track down costs on the type of SKU (in the case of Virtual Machines)? Business professionals are lost here.
What if…it breaks
Since new features and new solutions are following each other at such a high pace, developers and other professionals need to be curious. Not only from the perspective of working software but especially when things break. Features that break should trigger someone that investigates the issue and determine if they can fix it themselves or if they require professional support (from the tool vendor). Having to wait for a tool vendor can delay releases and cause other problems such as unwanted workarounds.
Therefore it’s important that the end-user can investigate everything that gives an error. Give them access to log files (with enough details), present proper classifications to errors such as “can I fix it myself” or do I require professional support. Point to documentation that handles common errors of the tool or mistakes (by the developers). This way, you really engage the end-user and give them the power to push their applications forward.
Reporting at the right level
Every tool that generates a lot of data needs to have a proper way to report it. Often, tools tend to present reports in a standard shape or form. End-users can select the data sets and the field they want to include in the report, but not the level of detail. Reports that show every single issue including for L1 and L2 engineers are not helpful for business managers.
Tools need to pinpoint reports to the (head of) CISO, CTOs, and perhaps even the CEO. That means: they need to quickly find the most important (security) issues on a very high level. It does not happen if those issues happen during build-time or run-time or what the level of the CVE is. They require information about the risks for the organization. Running a business is all about risk management and ensuring business continuity. Reports should focus on those topics instead of low-level issues that can (and should) be solved on the operational level.
Professional support
Enterprise-grade companies seek professional support since they require fast access to knowledge in case of (major) disruptions or problems. It is not enough to rely on “the community” to find answers. In addition to that, companies might demand features that are not available yet. In many cases, they request the vendor which can accept or reject the request. Whatever the outcome is, the answer should be clear so companies can plan forward and make decisions about it. Without professional support at the side of the vendor, this is not possible. No guarantees when working with a community-driven product.
A vendor that offers professional support needs to have fully adequate knowledge of the product. Their advice needs to be consistent, up to date, and also within the context of how the organization uses the product. Suppliers need to attract people that both works on the business side as well as on technical aspects to fully support the customer.
Instructions on how to perform certain tasks or implement features should be adequate and also aligned with corresponding technologies. For example: follow the latest trends and changes of Cloud providers since they regularly change their interfaces, specifications, or implementations without notice. Professional support personnel needs to constantly keep an eye on it. Communicate it back to the business professionals on the side of the customer.
Focus areas
No tool can do everything a person wants. Business professionals seek the sweet spot between the number of tools and the problem area they’re trying to solve. Consider one tool that handles every security-related problem in every phase of the Software Development Life Cycle, that tool would be the most popular in the entire world. This is not the reality.
Every good tool specializes in some sort of problem area in which they perform best. It’s the homework of business professionals together with the technical experts to find this sweet spot. Perhaps it requires conducting a Proof of Concept to verify the most critical features of the tool. When doing so, take into account the main tech stacks or applications which are in scope. Only then, you can make an informed decision about what the tool can offer.
Suppose the tool in charge is best in class for 2 out of 3 problem areas you’re trying to solve. Then you require another tool or solution to cover the last problem area. Organizations need to negotiate about the price and the quality of the tool and also conduct another tool assessment. This might even lead to internal conflicts or confusion about its scope. Therefore, business professionals need to be very well informed and act responsibly.
Informative dashboards
Don’t underestimate the role of dashboards. Often, technical professionals seek deeply technical solutions whereas business representatives demand proper high-level information. Various bits and pieces of security-related information come together in so-called “dashboards”. For security products, dashboards can show the number of (new) vulnerabilities, the total risk score of them, the severity of issues, the number of policy violations against the compliance frameworks and rules.
It’s crucial to customize any dashboard to zoom in into focus areas from a business perspective. For example group security incidents by business application or by the team. Perhaps it’s even possible to aggregate on technology stack or business department. That makes more sense than all incidents on a single level and split it based on “raw low-level data” such as cloud service or severity. It’s about the business context and not the operational point of view.
Tool vendors that really want to penetrate the market seek business-driven solutions and build features to tackle these. Speed of delivery is a key aspect in every organization that builds software. Therefore, business professionals seek features such as auto-remediation for security issues. However, that should result in additional problems such as broken builds, backward incompatibility, or new security issues. In short, the “technical debt” should not increase thus the business risks AFTER the auto-remediation should decrease not increase. Given this, these options require a thorough analysis of technical security experts that know what the (potential) impact is on the application or resource in charge.
Archive it!
No one can escape the auditors. Since companies are responsible for process (sensitive) information of customers and other stakeholders in a responsible way, they might face audits at given points in time. Often auditors demand access to processes and the way companies are “in control” of whatever happens with the data they store and process. Governance-related aspects are part of the responsibilities of the business professionals, not the tech guys. Auditors might demand insights of information that is current as well as archived data.
Security tools that generate a huge number of alerts, security triggers, tickets, reports, statistics, etc also require a proper feature to archive whatever is irrelevant. Organizations should be able to choose which information (based on their criteria) needs to be archived to keep the information overflow limited. This also helps the operational guys focus on the things that really matter in their day-to-day operations. Less is more, especially when it comes to splitting workloads into the right priority.
Final words
Great security tools do one job very well. Despite the fact that the tech guys might be the primary target group to work with these tools, business professionals also have a big say in what the tool should offer and which problem area needs to be solved. In this article, I presented several topics that can be seen as feature (requests) to tool vendors from the business perspective. In the end, it’s the business that holds the budget and thus making or breaking a successful implementation of the tool.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
