Why does someone “do security”? Why do companies buy firewalls and other hardware or security software and services? Why does someone enforce compliance with regulations like PCI or GDPR?
Simply put, proper security is good business practice.
“But,” you might think “I follow GDPR because I am required to comply with that regulation.”
When you really think about it, you follow GDPR because it is good business practice for you to comply with that regulation. The same is true for PCI – if you are PCI-compliant, you can continue to accept credit cards. It is good business for you to accept credit cards, just like it is good business to avoid fines associated with lack of compliance with GDPR. In most cases, you have choices on how compliant you will be – paying the fines is a business choice. But, being non-compliant not only potentially costs you fines and opportunities, it can be bad for your reputation, and therefore, not good business practice.
Every successful organization has business goals and objectives. Those goals and objectives are designed to help identify how the business measures success, or at least how to move the business forward on a successful path. Those goals generally have more to do with focusing the business than they do with “security”.
“Security is an enabler.” This has been a mantra of security professionals for a very long time. If you have sensitive information – business secrets – which you want to protect from people outside your organization, like your competitors, then you have a business requirement to protect that information. That means, for good business reasons, you need to encrypt the information, protect it on an internal network, perhaps behind a firewall, and perhaps on a protected subnet. Perhaps you add some classification handling guidelines and limit access to specific staff who need access to those secrets. The fact that those are also security requirements is kind of incidental. They are requirements to help you meet your business goals in a safe and secure manner.
Let’s say you are a bank, and you are holding funds for commercial and consumer customers. If you don’t include any security controls in your business requirements, you might store that cash in cardboard boxes on desks in unlocked office space. In that situation, how long will that cash last before it is lost or stolen – by accidents, outsiders or insiders? Because, counting and auditing the amount of cash, protecting the room with a sprinkler system, locking it in a vault, alarming that vault – those are all security controls. But they are also business controls because they help you stay in business and meet your goals for market share and shareholder value. If you included no security in your operations, your data would be stolen, and you would be quickly out of business.
Successful organizations know this and embrace it. When I was working for the CIA in 1984, every new project was required to include a business plan which included all operational and security requirements associated with the project right in the basic project definition. Does it need encryption? Backup storage? Cold or hot spares? Secure communication pipe? A TEMPEST cabinet? Can it be installed in office space or does it need to operate in a secure vault? What kind of training will a user require? A project submission without embedded security requirements was not a valid project submission and pretty much automatically rejected. A proper project submission included everything needed to field and operate the system in a safe and secure manner, meeting all identified business requirements of the organization.
The impact was that “security” was part of the basic project requirements. This also means, there was no security add-on – so no security return-on-investment to calculate. Validation and consideration of relevant security requirements is just as important as considering if you should buy hardware, or software, or documentation, or training. And, it includes how you source the capabilities you use to fulfill project requirements. Are you going to build your own hardware or buy it from a third party? Are you going to write your own software, or are you going to buy it from a third party? Are you going to manage your security program or buy it from a third party?
But even at that level, security is not about “security”; it is about whether or not it supports or enables the business. To keep that process simple, consider this approach when developing a new project.
- Define business need.
- Define supporting security requirements.
- Does the security requirement directly support a business need?
- If “Yes”, then proceed.
- If “No”. then go to 1.
Even security geeks need to understand that information does not exist for its own sake. Security exists to allow the business to thrive and succeed.