Cyber-security as a field is concerned with protecting digital assets. It may conjure to mind dark rooms and hackers and hoaky 90s CGI imaginations of what the inside of a mainframe looks like ala Tron. In reality Cyber-security has a lot more to do do with the security half of its name rather than the the cyber half. Any digital asset (data bases, web-servers, secret files, etc) still has to exist physically on a computer somewhere and that somewhere has to be physically secure in order for anything on the machine to be secure. The need to be physically secure means that conventional security practices are still relevant when considering digital security, it’s just that when an asset is digital it exists as information that can be transmitted over the internet, so there’s additional aveneues of access we need to control.

some core vocabulary

Let’s now take the time to establish some precise vocabulary used within cybersecurity. This whole time I’ve been using the word “secure” but what exactly does that mean? There a few definitions of differing level of detail, but the most common definition you’ll see makes use of something called the CIA triad, an acronym that covers the three main attributes of security. We consider information secure only when it meets all 3 attributes:

• Confidentiality: Private information is kept private. If we have someone’s credit card number, we want tp ensure that information isn’t learned by the public or a third party. Risk factors include data leaks like heart-bleed, intentional espionage, and accidentally publishing internal documents.
• Integrity: All information we have is correct. Potential risk factors include random data corruption as well as intentional altering of records.
• Accessibility: We can always access our information when we need it. We can stop anyone from extracting the data on a usb stick by destroying the usb stick. But, that doesn’t mean we’ve secured the information, since now we can’t access it either. Risk factors include natural disasters shutting down our server, and ransom-ware encrypting our data.

In providing the examples above, I’ve introduced a new piece of vernacular: a risk factor is any event that could compromise the security of our digital asset, from hackers,to natural disasters, or a trusted member of the organization unintentionally deleting or sharing information.

We create assurance of security by implementing what we call security controls. Controls are any policy or infrastructure we use to mitigate risk factors. Some examples include:

• badging into a building (by preventing 3rd parties from entering a space we enforce confidentiality)
• duplicating data (by creating back-ups we protect accessibility in the case of a server shut-down)
• keeping change logs (we can undo any incorrect changes to re-establish integrity).

(as an aside: notice how we can usually sort controls by how they affect one or more of the items in the CIA triad)

Controls can be divided into preventative and reactive controls. Preventative controls look to prevent a security risk from happening. Reactive controls look to detect, record, and undo a security risk after it’s happened. In general we need a blend of both since prevention is good, but if we cannot detect and recover from a security breach, then we cannot trust our information’s integrity.

Other terms of art include:

adversary

a malicious third party actively trying to breach your security, usually used to refer to an imagined person for the sake of thinking through risk factors than an actual real life individual.

asset

anything we’re trying to protect. In cyber-security, that generally means a digital asset or information asset.

risk

understanding what can go wrong, and how likely it is, is the first step of security. Technically we can implement security controls without thinking through what could happen, but that’s a good way to end up spending a lot of effort somewhere it’s not needed. Instead, we can do a risk assessment and build up a risk profile of risk factors relevant to our asset, the probability of those risks and the magnitude of consequences should those risk factors occur. We can then use our risk profile to decide on our risk management strategy and security controls. Thankfully, we don’t need to spend all day catastrophizing and thinking up all the ways thing can go wrong all on our own. There are wonderful organizations that have put together risk catalogues or risk registers: compendiums of potential risks for us to peruse and think through.

Risk management strategies can be catagorized as follows

• risk modification (reducing probability)
• risk mitigation (reducing the potential damage)
• risk acceptance (the risk will just happen, oh well, it’s not worth fixing)
• risk sharing/distribution (like an insurance plan that pays out, or subcontracting out)
• risk avoidance (simply cut off the risk bearing part and stop doing it), used when the asset is low value but high damage.

note that without proper security practices we’re living with risk acceptance by default.

Example

Imagine we are a small org with lots of field workers, called CommunityCheck. Those workers go out to talk to multiple constituents a day and bring with them a clipboard of information from the org as well as any notes they take in the field. One potential risk factor is that, if they keep all their notes on the clipboard uncovered, they might accidentally show a constituent’s private information to someone else while just walking around.

We could try to avoid the risk completely by either ceasing field work or preventing field workers from bringing any information with them. If field-work isn’t very important to our org that might be worth doing. We could also share risk, ceasing our own field work but contracting it out to another organization. But given we have so many field workers, lets say field-work is essential enough that we have to keep doing it ourselves.

We could modify risk by providing field workers with opaque binders, so that no information is visible until they open the binder while talking to a constituent. We could mitigate the risk by creating policies around what information can be brought into the field and how many constituent’s information a field worker can have on hand at once, so that if an exposure happens the information at risk is less of a privacy violation and less constituents are affected.

security principles

Some common best practices to help keep our assets secure include:

• security controls need to be simple enough that they can be easily audited and verified.
• rely on positively identifying benevolent actors. Adversaries can always pick a new unrecognized strategy, so trying to identify and exclude malicious behavior is a losing game.
• security through obscurity/secrecy is not security at all.
• principle of least privilege: every individual should only have the bare minimum security clearance in order to do their job.
• usability: if a security control is too much of a hassle, the people who are meant to use it won’t.