This essay originally appeared in the RSA Conference Blog
When someone launches a startup, or a new line of business in an established enterprise, at some point, sooner or later, they need to decide how to handle cybersecurity. They may have already postponed implementing cybersecurity several times, using excuses such as “it does not make sense to spend on security before we get revenue”, but they can’t delay onboarding security into their organization forever. Contrary to popular belief, launching cybersecurity initiatives doesn't necessarily require extensive financial investment or vast resources. To begin, organizations need to answer several questions. While getting help from experienced professionals is ideal, they can certainly tackle this process themselves if that's not an option.
The first question to ask: “Who is the person responsible for making decisions regarding security?” Even if a high‑ranking manager is tasked with this story, that person is not necessarily the one who should carry it out. Holding responsibility for a particular part of the business—say, technology—creates a conflict of interests, so the task should be escalated to a higher executive—or ideally, the business owner—who cares about the long‑term success of the business. Putting the wrong person in charge of security is the number one security vulnerability in organizations.
Assume for a moment that the decision‑maker is also the one who cares deeply about security. The next four questions that must be answered are:
The process of answering those questions is called risk assessment. This can be done by the business owner and does not need to be done by a security professional.
While advanced steps like threat modeling and quantitative risk assessment are best left to professionals, an initial review offers crucial insights into future challenges and better prepares teams for expert collaboration. Now, let's explore those four questions.
First, review the available data—whether organizational, customer, or both—to determine its criticality to ongoing operations and to customers. If the business cannot continue operating once such data is lost or stolen—for example, payment data, healthcare records, or deal records—the answer to the first question is the data is critical, and adequate controls must be designed and implemented to protect confidentiality and integrity of the data.
The good news is that in many cases there are some laws or industry regulations that protect critical data, for example, Payment Card Industry Data Security Standards (PCI DSS) for payment data, or HIPAA for healthcare records, or General Data Protection Regulation (GDPR) for personally identifiable information (these regulations can help answer question three about compliance). But that’s not always the case. For example, an organization might store transaction data that is not classified as sensitive under the regulations above but is, in fact, sensitive because it reveals extensive information about customers and business activities. The lack of regulation in a particular business area does not mean the data is not attractive to hackers.
Question two is also partially about the data but different aspects of it: availability. At this stage, it is crucial to understand the impact on the business if service to customers cannot be maintained and to define the maximum tolerable downtime. When a Service Level Agreement (SLA) exists with customers, this task is going to be simple as the required availability is typically defined therein. In the absence of an SLA—or when downtime parameters are not defined—the required availability should be estimated based on common sense. To clarify, examples of threats to availability include Distributed Denial of Service (DDoS) and ransomware attacks. Both can cause short or long-term downtime, so when continuous service is essential, adequate controls must be implemented. However, if the data is readily restorable—for example, statistical records that can be rebuilt from other sources—it may be acceptable to go easier on security protections.
One important tip: note that the attack vectors (and therefore corresponding security controls) are different when it comes to protecting confidentiality and availability of the same data. For example, a sophisticated Data Loss Prevention (DLP) system can protect against information leaks, preventing attackers from exfiltrating data. But ransomware attackers don’t care: need the data itself. What they do is delete the original data, replace it with an encrypted copy, and demand payment for the decryption key.
Question three on compliance—previously discussed briefly—if the data and environment fall under any relevant regulations, qualified assistance is recommended for two reasons: a formal assessment and certification process will be required, which is not trivial. More importantly, compliance requirements don’t appear without reason: the data must be valuable to hackers, making the business a desirable target that is worth it to spend significant efforts and resources to break into their premises.
Finally, the reputation question. Although protection company reputation seems to be obvious, it is amazing how many business owners ignore it. Even low‑profile data that can be easily restored may still be targeted by attackers for various reasons, sometimes just for fun. Suppose attackers breach a development environment containing no production data, steal the contents, and publish them on so‑called data leak or shame sites. Although the stolen data may have little intrinsic value, the mere fact of the breach can lead existing and potential customers to assume that their production data is equally vulnerable.
Getting started with cybersecurity doesn’t require perfection—just informed, intentional steps. By asking the right questions early, a solid foundation can be built to protect the business, its customers, and its reputation.
When someone launches a startup, or a new line of business in an established enterprise, at some point, sooner or later, they need to decide how to handle cybersecurity. They may have already postponed implementing cybersecurity several times, using excuses such as “it does not make sense to spend on security before we get revenue”, but they can’t delay onboarding security into their organization forever. Contrary to popular belief, launching cybersecurity initiatives doesn't necessarily require extensive financial investment or vast resources. To begin, organizations need to answer several questions. While getting help from experienced professionals is ideal, they can certainly tackle this process themselves if that's not an option.
The first question to ask: “Who is the person responsible for making decisions regarding security?” Even if a high‑ranking manager is tasked with this story, that person is not necessarily the one who should carry it out. Holding responsibility for a particular part of the business—say, technology—creates a conflict of interests, so the task should be escalated to a higher executive—or ideally, the business owner—who cares about the long‑term success of the business. Putting the wrong person in charge of security is the number one security vulnerability in organizations.
Assume for a moment that the decision‑maker is also the one who cares deeply about security. The next four questions that must be answered are:
- How critical is the data (both organizational and customer data)?
- How critical is the availability of the product or service (availability is defined below)?
- Does the organization need to comply with any laws or industry regulations?
- And finally: How important is the organization’s reputation?
The process of answering those questions is called risk assessment. This can be done by the business owner and does not need to be done by a security professional.
While advanced steps like threat modeling and quantitative risk assessment are best left to professionals, an initial review offers crucial insights into future challenges and better prepares teams for expert collaboration. Now, let's explore those four questions.
First, review the available data—whether organizational, customer, or both—to determine its criticality to ongoing operations and to customers. If the business cannot continue operating once such data is lost or stolen—for example, payment data, healthcare records, or deal records—the answer to the first question is the data is critical, and adequate controls must be designed and implemented to protect confidentiality and integrity of the data.
The good news is that in many cases there are some laws or industry regulations that protect critical data, for example, Payment Card Industry Data Security Standards (PCI DSS) for payment data, or HIPAA for healthcare records, or General Data Protection Regulation (GDPR) for personally identifiable information (these regulations can help answer question three about compliance). But that’s not always the case. For example, an organization might store transaction data that is not classified as sensitive under the regulations above but is, in fact, sensitive because it reveals extensive information about customers and business activities. The lack of regulation in a particular business area does not mean the data is not attractive to hackers.
Question two is also partially about the data but different aspects of it: availability. At this stage, it is crucial to understand the impact on the business if service to customers cannot be maintained and to define the maximum tolerable downtime. When a Service Level Agreement (SLA) exists with customers, this task is going to be simple as the required availability is typically defined therein. In the absence of an SLA—or when downtime parameters are not defined—the required availability should be estimated based on common sense. To clarify, examples of threats to availability include Distributed Denial of Service (DDoS) and ransomware attacks. Both can cause short or long-term downtime, so when continuous service is essential, adequate controls must be implemented. However, if the data is readily restorable—for example, statistical records that can be rebuilt from other sources—it may be acceptable to go easier on security protections.
One important tip: note that the attack vectors (and therefore corresponding security controls) are different when it comes to protecting confidentiality and availability of the same data. For example, a sophisticated Data Loss Prevention (DLP) system can protect against information leaks, preventing attackers from exfiltrating data. But ransomware attackers don’t care: need the data itself. What they do is delete the original data, replace it with an encrypted copy, and demand payment for the decryption key.
Question three on compliance—previously discussed briefly—if the data and environment fall under any relevant regulations, qualified assistance is recommended for two reasons: a formal assessment and certification process will be required, which is not trivial. More importantly, compliance requirements don’t appear without reason: the data must be valuable to hackers, making the business a desirable target that is worth it to spend significant efforts and resources to break into their premises.
Finally, the reputation question. Although protection company reputation seems to be obvious, it is amazing how many business owners ignore it. Even low‑profile data that can be easily restored may still be targeted by attackers for various reasons, sometimes just for fun. Suppose attackers breach a development environment containing no production data, steal the contents, and publish them on so‑called data leak or shame sites. Although the stolen data may have little intrinsic value, the mere fact of the breach can lead existing and potential customers to assume that their production data is equally vulnerable.
Getting started with cybersecurity doesn’t require perfection—just informed, intentional steps. By asking the right questions early, a solid foundation can be built to protect the business, its customers, and its reputation.
RSS Feed
