When we create an environment and consider our security testing from development to production and how changes are deployed throughout each environment, we want to consider what we’re protecting and how much resources we’ll devote to this protection. Every company has limited resources, so protecting against all possible threats will not be something we can achieve.
Note: To learn more about Data Protection and Data Privacy, please read Data Protection and Data Privacy — How Do You Really Protect Your Users’ Information? article.
Networks Are Never Fully Secure
In Alex Gibney’s Zero Days documentary, a former deputy director of the NSA, Chris Inglis, admits that during Operation Buckshot Yankee, his team realized that they could never fully secure a network from outside attacks. In the same film, this conclusion is echoed in several other interviews with individuals working in the private cybersecurity industry. We cannot stop attacks. We cannot even protect against all attacks. At best, we can delay or deter attacks. Our security testing should consider these points. Rather than a mentality of how do we stop attacks and promote this approach throughout our environments (we can’t), our mentality should be what is our priority to secure, how can we best secure it, and what steps should we take to secure it.
Starting with the assumption that we can’t stop attacks helps us focus our efforts on where we’re likely to see the strongest results to protect in our environment.
Identifying Areas of Concern
Before we consider security testing, we should consider that some hacks have different intent than others. When we know what types of attacks exist, we can determine where we’re most at risk and prepare. Examples of different attacks could be:
- Destructive attacks – hacks intended to destroy resources (i.e., “drop table”)
- Informational attacks – hacks designed to obtain information about a target (i.e., Duqu)
- Intellectual property attacks – hacks designed to steal intellectual property (i.e., industrial espionage)
- Mis-directional attacks – hacks designed to confuse the target into wasting resources
Depending on our risks, our security testing must focus first on the highest risks. In the below image, we see four types of businesses built around data, design, operations, or niche models and the types of attacks that are likely to do the most damage. Keep in mind that some businesses are a combination of the four models, such as data and design (common with software companies) or operations and niche (common with gold mining companies):
Before designing our security testing, we should know what types of attacks will do the most damage to our business.
Other attack types exist, but these cover some of the most common attacks we see. As we see, the intent of hacking differs, and some hacks may be positive to help a company strengthen its environment (ethical hacking).
Examples
As we’ve seen, our first step to protecting our company is to identify our business model and what attacks we’re likely to experience.
For an example, on a database level, we may be able to prevent a destructive hack from outside our environment through restricting all external users to readers, but it’s possible that an attacker only wants information and uses techniques to extract information about our database with the reader permission we’ve granted. If our situation calls for preventing an informational attack over a destructive attack, we would possibly want permissions isolated on an object level. Our security testing must prioritize the risk of an informational attack over a destructive attack if our business model calls for this protection first. Also, protecting data significantly differs from protecting design – in most cases, we want to limit data in environments and on reports to only what is necessary. A common practice we see in the below image is to limit priority data – like PII data – to pre-production and production while generating “placeholder” data (i.e., fake data) in lower environments for testing purposes.
A software development cycle where pre-production and production are the only environments with PII data
Even intuitive designs that enhance user experience must have robust security testing, as these designs may have weaknesses that allow for infiltration or may provide too much information. For a simple example of this, in the below login form, when entering an incorrect email address, a message warns the user that no login is associated with an email. At first glance, this seems helpful to users, as it may help them identify if they’ve accidentally entered an incorrect email account. However, this compromises our system as it identifies who has an account and opens the site to an informational attack that anyone can use.
Basic security testing should fail this form as it provides too much information to the user that exposes us to risk.
Relating to the challenge presented in the above image, our security testing would need to identify this input-output risk. By identifying this risk early in our environments, we would be able to stop it from ever entering higher environments and putting legitimate users at risk.
Keep in mind that hacking in the context of manipulation outside of intent isn’t only limited to the digital world. Social engineering is fundamentally a form of a hack through manipulation and one that uses social techniques rather than digital. Sometimes, it combines both (social media being a mixture of social and digital). This falls outside of testing code, but we should still be testing for social engineering as this area can be costly and easily overlooked. In general, where input exists, injection risks are possible with the malicious intent of getting more output – and this isn’t limited to the digital world.
Summary
When we review the attack vectors of our environment that we must protect against along with the security in place in our environment, we can create the appropriate security testing for development teams where we are most at risk. Whether we’re protecting data, intellectual property, or destruction, we want to create secure architecture that allows for these checks during builds and deployments. This insight allows developers and security personnel the ability to quickly identify areas of weaknesses and improvements to further increase security.
He has spent a decade working in FinTech, along with a few years in BioTech and Energy Tech.He hosts the West Texas SQL Server Users' Group, as well as teaches courses and writes articles on SQL Server, ETL, and PowerShell.
In his free time, he is a contributor to the decentralized financial industry.
View all posts by Timothy Smith
- Data Masking or Altering Behavioral Information - June 26, 2020
- Security Testing with extreme data volume ranges - June 19, 2020
- SQL Server performance tuning – RESOURCE_SEMAPHORE waits - June 16, 2020