Basics for Information security
Part 1
Intent:
This Post is introductory to parlance in the security field for anyone who’s not from security background. Because people have intentionally made simple concepts harder to understand by bringing in argot terms to the table.
First thing first:
Before we dive-in to information security, one has to understand the difference between information security and physical security.
Information security: The security which is provided by using cryptographic techniques, logging, and access control in digital system.
One could encounter this type of security often in websites boasting themselves by advertising users that they use AES-256 encryption to secure your details.
Physical security: The security which is provided by physically securing the system.
This could be something as simple as securing your car by keeping it the garage rather than leaving it outside.
Throughout the Post, “security” could be replaced as “information security” wherever possible. It is common to refer info-security as just security unless and until specified.
Terminologies under discussion:
Security Asset
Security Objective
Security Goal
Security Policy
Security Asset: During any assessment of any system in terms of security, we gather assets that need protection from malicious actors. Security assets are precious function, data or communication which have high impact on business.
How to know if something qualifies as an asset?
1. An asset should be a digitally stored data or communication or a functionality.
As we are dealing with information security we can’t have something physical as an asset.
2. Asset is something which upon exposure or tampering or unavailability could lead to an damaging event.
Damaging event could be business impact or legal issues or functionality impact or all.
Example: Let us take a website login page.
During a security analysis, one would find that these details have to be secured from being accessed by others (malicious actors) who are not allowed to see/modify them in the internet. From mere common sense, it is evident that user credential is an asset that we want to protect from malicious actors, but we should always check whether it qualifies to be a security asset.
- User credentials are digital data in a communication — Passes the 1st criteria.
- Exposure of user credentials could lead to account take over; a disastrous event for any website to have its users hacked — Passes 2nd criteria.
Security objective: Objectives are the aspects of a security asset that would be protected from the malign actor. Many objectives are depending upon the asset in information security. But ultimately, everything boils down to three main objectives Confidentiality, Integrity, and Availability (CIA).
To keep the introduction simple let me vaguely define what CIA individually stands for:
C — Confidentiality — When an asset requires concealment of the information in it from users/actors other then the intended ones, this objective is chosen for the asset.
I — Integrity — When an asset requires tamper detection or to know if the information is authentic, this objective is chosen for the asset.
A — Availability — When an asset requires to be up and running, in case it fails it would bring up negative impact, this objective is chosen for the asset.
There could be cases where one asset is mapped to multiple objectives, this system implementation depend.
I might want to check authenticity of the information received and also want the information to be confidential as well. This is commonly encountered when passing login credentials between browser and web-server.
Example:
The Webserver gets messages, stating the source, “A send it.” The Webserver has to check if the source of origin is really from “A” or someone else; Source“B” sent the message by impersonating as “A.”
Here integrity check of messages is required.
If the message contains login credentials, then no one except Webserver and browser should be able to understand the message that could be done by encrypting the message.
Here confidentiality of messages is required.
From above, we can state that confidentiality and integrity of communication between a web browser and Webserver are required.
Security Goals: Security Objectives when combined with security asset are called as security goals.
Security Goal = Security Asset + Security objective
Example:
Let us take the previous example where my asset was communication between browser and web-server, my objectives for the asset were confidentiality and integrity.
Then my security goals for the system would be:
1. Confidentiality of communication between browser and web-server
2. Integrity of communication between browser and web-server
Security Policy: policies defined for the system to meet the security goals are called as security policies.
Everyone can implement there own policy to meet the security goals for a system. But, one has to keep in mind that when making a new policy, all the underlying assumptions are valid under all circumstances.
Let me elaborate this:
There are cases where when a social media site had a password reset policy to verify the user who forgot the password but crosschecking his last 6 digits of a credit card (credit used for billing).
The policy assumes that the information of credit card last 6 digits is only known by the user.
If there were to exists a case every an adversary could know his credit card number using other means, then the assumption that only legit user knows the information becomes invalid and this leads to the exploit-ability of password reset policy.
One should keep in mind the underlying assumption should be always valid. Best practice would be to keep the policy independent of information which could be gathered from other sources/systems.
Next post on:
Asset
Vulnerability
Threat
Exploit
Payload
