|
451 Research’s Information Security, Vendor Evaluations 2021 study delves into a deeper analysis of perceptions around two primary sets of tools supporting security teams: application security and security information and event management (SIEM).
Application security testing generally means the integration of different types of testing throughout the development lifecycle – for example, static AST in code construction; dynamic AST, which attempts to simulate attacks against an application; or software composition analysis, which can be applied in various places to gauge an application’s exposure to open source risk. There is an increasing need to make the use of these tools as frictionless as possible for developers due to that integration.
While security buyers tend to go ‘best of breed’ (66% indicate that preference in this survey) in most of their decisions, application security is a bit of an outlier where a portfolio approach is favored. Fifty-three percent of respondents note the portfolio of offerings from a vendor as a 'very important' differentiator in selecting a vendor. This is likely due to a desire to see a smooth integration of testing into developer and DevOps toolchains, compiled results between different forms of testing, collaboration between shift-left and shift-right (protection) strategies, and an emerging thought that these results must be somehow prioritized because developers aren't going to be able to fix everything. Maybe some of that prioritization exists in the findings that appear across multiple tools, sometimes in different forms.
|
| |
|
Key takeaways from the survey
|
| |
|
|
AST is in use at 41% of enterprises, 61% of very large enterprises (those with more than 10,000 employees) and 80% of enterprises with in-house application development teams, reflecting its role as a security technology primarily aimed at organizations that have developers writing code. When it comes to selecting an AST vendor, table-stakes features like programming and platform coverage rank as highly important to 55% of survey respondents, as does the product and service portfolio of that AST vendor (53%).
|
| |
|
|
Forty-eight percent of those using AST tools are able to leverage those tools in testing vendor products used by their organization in addition to their own products, which is one form of applying security testing to their organization's software supply chain. The usage of the tools remains a collaborative affair. When asked to allocate usage between the two primary teams involved, information security makes up a 54% share on average, while application development is at 46%. This remains a far cry from the percentages in the initial survey that asked this question in 2015, in which the information security team was allocated 71% of the usage of AST tools. This reflects the continued evolution of the 'shift left' strategy whereby more testing is applied earlier in developer pipelines – 52% of respondent organizations are performing AST as new code is written.
Reflecting the explosive growth of web API usage to support microservice architectures and points of production integration, 58% view the ability to test APIs as very important. Seventy-six percent of respondents note that API security is very important to their security strategy; this rises to 84% in enterprises with more than 10,000 employees, who likely have a greater dependency on API usage.
SIEM tools are in place at 59% of surveyed enterprises and at 84% of very large enterprises (more than 10,000 employees). SIEMs serve as a primary collection point for sources of security intelligence, notably logs produced by systems, tools and applications, and provide the ability to query and alert for triggers that would indicate a security issue requiring investigation. That role makes the SIEM a point of integration for other technology – for example, providing internal context to compare third-party threat intelligence against, which 49% of respondents note they are able to do. While most SIEMs are deployed on-premises (31%), a significant percentage are consumed as SaaS (28%), leverage a managed security services offering (21%) or use a cloud-based tool (20%).
|
| |
|
|
Given the nature of SIEM tools, it is not surprising to see 72% of respondents note that the quality of reports and alerting is very important when selecting one. The second feature where the greatest percentage of respondents selected 'most important' is the previously mentioned use case of integrating and correlating external threat intelligence against the data collected by the SIEM.
Outside-in security refers to the concept of providing a security assessment from the point of view of an attacker. Enabling security technology examples include, but are not limited to, classic external vulnerability assessment, attack surface management, and continuous automated security controls testing and validation. The three most common approaches to addressing outside-in security, per respondents, include third-party vulnerability assessments (54%), leveraging managed security services (47%) and traditional third-party penetration tests (47%). The fourth-most-cited approach, risk-based vulnerability management, involves prioritizing the vulnerabilities identified in a scan against the context of the assets that are found vulnerable. This second piece is a departure from earlier approaches that relied on an assumed risk of the vulnerability itself, and instead provides a more actionable prioritization of vulnerability scan results by leveraging an understanding of which assets are the most critical, in addition to the severity of the vulnerability.
|
| |
|
| |
|
Targeted attacks, including ransomware, almost always have a privilege escalation step after an attacker gains an initial foothold within an environment. Disrupting this step, and making lateral movement more difficult, thus becomes a goal of enterprise security. The most-cited steps surveyed organizations have implemented include multi-factor authentication (64%), increased logging (48%) and privileged access management (43%). PAM tools take on the somewhat contradictory, but necessary, step of applying a principle of least privilege to elevated access or privileged accounts. An example of such superuser accounts is 'Administrator' accounts in Windows.
|
| |
|
|