We promised not to try to teach security; but there are a few high-level concepts that are worth understanding as a security program is pulled together.
Offense vs Defense
Offensive security activities are the domain of the “hacker” (using the more modern definition). These activities might be done by a “white hat” who is seeking to improve security by identifying vulnerabilities or they might be done by an unscrupulous “black hat.” There are also security researchers who operate in a somewhat gray area in between. Defensive security on the other hand are all of the things that we try do to thwart attack.
The classic “white hat” is a security expert performing a Penetration Test or Security Assessment. These activities and the technology surrounding them are important from two different perspectives:
- They directly identify previously unknown vulnerabilities
- They inform the defense in much the same way that an American football defensive line needs a detailed understanding the opposing offense.
A related activity is Cyber Forensics. This is using technology to understand an attack that happened in the past or even one that is still under way. Attackers may go to great ends to try to avoid detection completely or to obscure details about the attack. System designers, on the other hand, need to invent mechanisms that make that difficult (for example logging that is immediately off-boarded).
Many types of Attacks
OWASP and other sources make it clear that there are many types of attacks. Successful penetration campaigns will often use a number of different mechanisms at different points in the attack – somewhat like a general using spy’s, artillery, and then the infantry.
Defense in Depth
This is the notion that there should be multiple layers of defense. This is a key driver for a security program that spans multiple roles. We need to be concerned about secure coding, secure design (use of proper protocols, etc), secure deployment, etc.
Security by Obscurity
This is a dangerous and outmoded approach to security; but it is all to easy to fall back on this in whole or in part. An example might be hiding a security key in an odd location on the filesystem.
Hear no Evil See no Evil
This is another dangerous approach where the team does not actively look for vulnerabilities. For example by having a stated or unstated policy of not engaging external Penetration Testers.
Plan for Incidents
You should assume that the the software component you are developing will be compromised. You will want to have a plan in place to deal with this eventuality. This is likely to also have an impact on the technical implementation.
Shifting Left
This is a popular but by no means a new notion with a new buzz-word. It is applied pretty much across the software field. The special significance for Security is bringing security concerns into the design and implementation as early as possible using techniques such as Threat Modeling. But the term can also apply to activities such as introducing exposure to certain security tools earlier in the development process as some tool vendors are inclined to do.