Many security vendors with high-end products only know one type of customer: the one with a robust security program. Large enterprises that have critical assets to protect, such as financial data or intellectual property, generally also receive both budget and cultural support to the extent that they can shop for the best-of-breed specialty products and even buy several of them to get the coverage they want. They can afford knowledgeable staff and enough hands and eyes to maintain security operations. However, the vast majority of organizations, particularly SMBs, but also some bigger companies, don't have enough IT or security resources to put even the minimum controls in place. We refer to the gap between the security haves and the have-nots as the Security Poverty Line (SPL), and addressing this potentially large market means more than just lowering prices.
What it looks like below the Security Poverty Line
Organizations below the Security Poverty Line have no in-house security expertise – in fact, they may not even have any full-time IT staff at all. If they spend money on a security consultant, they may be able to get advice, but security also lies in the day-to-day execution, and without knowledgeable resources at their disposal, they won't be able to execute on whatever the consultant advises. For example, an enterprise security information management (ESIM) product may just sit unused if nobody has the time or expertise to tune it over months, or if the small staff has no time to read its reports. Even antivirus software can't be effective if it's not installed on every endpoint, and while the attack signatures may update automatically, the client and server software itself also needs to be updated periodically, and this can't always be done without IT staff laying hands on keyboards. In an IT-poor organization, maintenance tasks take a back seat to the more pressing matters of outages and new installations.
For this reason, organizations under the SPL are disproportionately dependent on their security vendors, both for knowledge and for execution. A more funded enterprise will have its own security team with its own set of experiences and opinions, and everything will be filtered through them; they will be more skeptical about the technology and marketing claims, and will assess them more closely against their understanding of the business risk. A lower-funded organization may leave it to the vendor to make configuration and operational decisions that affect business risk – in essence, it is outsourcing security risk management, possibly to a level that the vendor would not ordinarily willingly take on for reasons of liability. A vendor may offer integration services to go with an initial procurement, but after the installation is done, it won't leave an engineer on-site to do the day-to-day work for the entire year.
The effect of low IT budgets on security
Beneath the Security Poverty Line, the IT budgets themselves are often lower, as well, so the infrastructure to be secured may be older, disorganized and highly customized. Technology refreshes do not occur often – if at all – and any security products will have to be able to accommodate endpoints, servers and network equipment from a different era. This problem is not limited to versions of hardware, operating systems and applications – one guiding principle for improved security is segmentation, and it may be impractical or too expensive to disentangle systems in order to firewall them or control their access to one another. In a low-budget IT environment, it is more likely to be running software that nobody understands or is willing to touch, and is more likely to have user accounts that are being used to run production jobs; these are big hurdles to implementing effective security.
In a security-starved enterprise, what IT staff there is may have very little actual control over the infrastructure. Even in larger organizations with a particular business culture, for example, there may be islands of departments that administer their own desktops, and neither a central IT staff nor a security staff will be able to install agents on them. The support of the network may be outsourced to one company and support of the servers to another, and, depending upon which one the IT group has any ability to influence, it may only be able to use a server-based or network-based security product. (See our spotlight, 'Span-of-control issues can stop security purchasing cold.') Without authority, the IT staff can't monitor systems, fix vulnerabilities or respond to incidents. Schools, local government and small retailers have been taken down for days by a well-known worm or a random website breach because they didn't have the ability to reconfigure the affected systems. Even big enterprises can be vulnerable to this problem: Sony's PlayStation Network has been under attack for several weeks, and has repeatedly suffered outages as a result; this may either be a case of multiple vulnerabilities being discovered and exploited, or it may be a case that the very large corporation is struggling to coordinate the necessary changes to fix one particularly widespread vulnerability.
For a low-budget organization, managed security services appear to be an ideal solution: There are no capital costs and no human resource costs for security management or expertise. However, for the reasons listed above, these organizations are not in a good position to evaluate the different types of offerings or to make sure they are being effectively covered. Even SaaS security products, which they can use themselves without needing to host them, may have had features stripped out in order to lower the price point (or in the name of 'simplification'). The enterprise version of a security product may not be more expensive due to the larger size or higher performance specifications (which generally only apply to hardware-based products), and it may not be more expensive simply because of the enterprise-wide licensing. If an organization chooses the least expensive offering in a security product line, it doesn't necessarily know what feature set it's really buying, or whether it will provide effective security or merely check a compliance box.
Does compliance bridge the gap?
Even the pressures of compliance don't necessarily help a small organization. MSSPs have told us that, for some of their new SMB customers, it was the first time they had even attempted to reach a compliant security state; before that time, the customers had simply taken their chances and hoped that they wouldn't get caught. On the one hand, very specific regulations such as PCI-DSS help a nontechnical organization understand some minimum baseline practices for security; on the other hand, they may also lead the organization into believing that they've done enough to keep breaches at bay – a guarantee that nobody in the industry is prepared to make.
Compliance requirements were also intended to push larger organizations into taking security more seriously; indeed, many CISOs have told us that compliance is the only way they can get security budget in a corporate culture otherwise uninterested in information security. In an enterprise that fears the auditor more than the attacker, compliance can force security to reach a low-water mark, but it can't enforce effective security – as companies are learning once they discover they've been breached.
Attackers are picking up on the security-poor organizations, both the ones that can't afford it and the ones that can't be bothered. In the Verizon 2011 Data Breach Investigations Report, 436 of its cases were in organizations with 10-100 employees. Small and medium-sized businesses are being attacked wholesale, often in an automated fashion; a company that assumed it was too small to fall onto the criminals' radar is now more likely to be wrong.
Approaches to a solution
For those below the Security Poverty Line, the analogy of financial planning may be appropriate: Everyone knows that saving for retirement and for emergencies is important, but a family that needs its whole paycheck for food and lodging doesn't have the luxury of putting money aside. It can't afford to buy longer-lasting items, even though they might save money in the long run, because it doesn't have the cash up front to pay for them (in other words, ROI isn't relevant). And the family will only be able to consult an expert at tax time, if at all, when compliance is the driving factor. Likewise, a security-impoverished organization may not be able to afford the bare minimums – a correctly configured firewall, anti-malware and anti-spam protection. (The Trustwave 2011 Global Security Report noted that 84% of the breached companies investigated had no firewall at all.) It may also, knowingly or not, be incurring a security debt as time goes by that it can't ever repay, in the form of old, misconfigured systems and vulnerable software.
Organizations without security resources need more than an annual compliance check or even a free penetration test – they need help from vendors that understand their particular needs and can guide them toward sustainable operational and security practices. The industry also needs more standardization in its security features so that nontechnical customers can better compare options and understand what they're buying – this includes security services, such as penetration tests, as well as security products. (Members of the security community are already working on a Penetration Testing Execution Standard to help in this area.) Finally, we need hardware and software that is innately more secure, so that security is no longer an afterthought that only the fortunate can afford to add later.
To apply for access to 451 Research insight, click here.
