Security 101

In recent years legislators have pushed for more regulations on the Tech Industry, and it’s evident that compliance has become a top priority.

In this series of posts, starting from this one, I will provide you with the details on how to analyze possible risks and build a work culture that sets data-protection as a vital stage within the development life-cycle.

But before we can start discussing the secure-software-development-life-cycle (SSDLC), we must examine what security is?  

C.I.A. Triad (Security)

When defining Security, we focus on three categories that make the C.I.A Triad, which stands for:

• Confidentiality – Only Authorized individuals are permitted to access private assets. 
  For example
  • A user should not be able to access other users’ confidential information.
  • A user can’t access resources that require a higher security role. 
  • An employee who isn’t authorized to access customers’ database should not be able to do so.

• Integrity – Means that data has not been tampered with by unauthorized access; therefore, it is reliable, complete, and can be trusted. 
  For Example, Our System must ensure that only authorized users can change their data.

• Availability  – The System must be available and responsive to the clients.
  An application’s uptime should be high, and the expected number is usually defined in the S.L.A. (service-level-agreement) with the customer. 

Security Stakeholders

What and who is impacted by the level of Security in our product and, therefore, defines the requirements of what is expected from us?

• State Regulations 
  First and foremost, as I said at the beginning of this article, legislators have taken an extra step in regulating the industry.
  GDPR in Europe and CCPA in the state of California are good examples of it.
  These regulations cannot be ignored, and even google had to pay large fines for violating these laws. 
  For Instance, Google was fined 50 Million Euros in France in 2019, H&M was fined 35 Million Euros in Germany, and the list goes on.
  Sure, this is a tiny fraction of such companies’ total revenue, but this is only the starting point of GDPR fines, as these regulations came into effect just several years ago.

• Industry Standards 
  You must apply the security standards required by the industry your product serves.
  Whether it involves Medical information (HIPPA ), consists of the use of credit cards (PCI), or financial information (GLBA). 
  It would be best if you research the industry standards relevant to your domain.

• Customers 
  Your customer may, and probably will, have its own unique requirement; you have an obligation to the organizations you give your services to.

• Reputation 
  Nothing worse than a lawsuit to break the trust the industry has in you.
  Moreover, you want to strengthen your customer trust by having various security certifications (SOC2, CISSP).

Who is responsible for Security?

Well, the obvious answer is everyone in the company, each in his or her field of expertise and the tasks one is responsible for, must have Security in mind from the get-go :

• Compliance Officer 
  Well, compliance is their job.

• Senior Management
  Defines the security requirements and standards to their teams.

• Product Managers
  Classifies the data’s level of confidentiality and the proper balance between Usability and Security.

• DevOps and Cloud Engineers 
  Block unnecessary ports, integrating VPN to the overall architecture, secure the accounts, detect availability issues, and many other responsibilities.

• Developers 
  Provide a secured product and test it for security; we will have a series of posts about it, so I will not focus on it just yet.

• Testers and Q.A.
  Attempt to breach the system and act as ethical hackers on behalf of the company.

• I.T. Personals
  Secure the company’s networks, hardware, internal software accounts, and others. 

General Threats Methodologies

Before analyzing specific threats, let’s review the general methods an attacker can use to harm our system and customers:

Identity Spoofing 
Impersonate an authorized user, using methods such as Session Hijacking, Brute force attack, Phishing, and others.

Data Tampering 
For example, intercepting a legitimate request to the server from an authorized user and changing it to make the server invoke an action it was not requested to perform.  

Repudiation
When a User denies being a part of a transaction.

A malicious user may change the logging of his identifications and then deny any involvement for specific actions. 

For instance, imagine that for each request the user triggers, the client-side code also sends the username as a GET  parameter (for logging purposes); a malicious user may change that parameter to deny any involvement in the application’s anomalies or business transactions.

Information Disclosure
An Application may expose details that should be hidden and may be used later by an attacker.

For example, a REST server that sends an entire stack trace of a server error, revealing a database query used to process the request, which an attacker can then use for his or her attack vectors. 

Elevation of privileges
Wrong users-roles management may result in unauthorized users elevating their permissions to view sections in the application they are not permitted to access. 

The 5 Stages of Ethical Hacking

To protect against hackers, we need to think and attack our system as an attacker would.

That’s the ethical part of ethical-hacking; we attack systems to find vulnerabilities that will help a real malicious attacker breach our system. 

An attacker will take the following steps:

• Reconnaissance 
  In this phase, we are gathering information that will assist us later in our attack.
  This information is also called the application’s footprint; we would like to know more about the “victim” to know the right attack vector.
  There are two categories of information gathering:
  • Passive
    here we are yet to interact with our “victim”; we first try to collect information about it, for instance:
    • Going on Linkedin and check what technologies the company uses. 
    • Visiting employees’ social media accounts and collecting information from them could help us guess passwords or emails for phishing attacks.
    • Checking press articles about the company. 
  • Active
    Active Information Gathering is an Initial interaction of the attacker with the application, without applying any automatic utilities.

• Scanning and Enumeration – Using automatic tools such as Nmap, Nessus, Burp-Suite, and others to detect the application’s vulnerabilities.
  The enumeration part is a triage on the various findings; for example, if we know that the victim uses tomcat 8, we will search for common vulnerabilities within tomcat 8.
  
  
• Exploitation
  Gain access and exploit vulnerable services, networks, environments.

• Maintaining Access 
  Once an exploit is performed, how can we maintain access to keep exploiting the system? after we are logged out, or the machine is rebooted, etc.

• Covering Tracks
  Removing malware accounts created or any other indicator for the attack flow, like clearing event logs on a Windows machine. 

Once we understand the attack methodologies, we must think on we can block each step as defenders:

1. 1. Think twice before you publish information on social media and the press.
   2. Check HTTP headers, hidden HTML tags, and run scan tools to understand what is exposed to potential attackers.
   3. Exploitation protection is a large topic, which we will discuss later on.
   4. Check your system for any malware and trojans.
   5. Use audit logs and monitoring system in a way that will able you to draw an entire flow of an attack after it happened. 

If an attacker passed one step, the next step should be even more difficult to go through; you need to break the events chain. 

Security Controls

Similarly, as there are general vulnerabilities and vectors of attack, there are known ways to protect against them. 

• Technical Controls 
  Scanning Tools and automatic penetration test utilities
  • Network Level Security
    such as:
    • Blocking Ports
    • Virtual Private Networks
    • Virtual Private Cloud
  • Application Level Security
    such as:
    • Data Encryption.
    • Data sanitization and validation.
    • Enforcing strong passwords
    • Locking user accounts after too many failed logins.
• Administrative Tools 
  • Architectural Risk Management – 
    We will discuss it more in-depth in another post.
    Basically,  It means drawing your entire architecture, including the flow of data through the various components, and analyzing the risk of data transferring from one point to another.
    
    •  
  • Security Oriented Code Review 
    • Review the code with consideration of proper security-oriented check-lists.
    • We will cover this subject in another article, but for example, consider the following questions you can ask as a reviewer?
      • Is the data being encrypted? 
      • If a breach did occur, can it be detected? And how? 
      • Have you checked the third party utilities that you are using have known vulnerabilities?

  • Security Training  
    • Awareness, awareness, awareness, the team needs to be aware of the various risks and learn how to mitigate them. 

Summary

I hope you enjoyed reading the first post on the SSDLC(Secure Development life cycle).

In this short introduction, you have learned what security is? Who are the stakeholders who determine the level of security? General details on the attack methodologies for ethical hackers and a short brief on security controls to mitigate various risks. 

In the next post, we are going to dig deeper into different attack vectors, as well as on how to mitigate vulnerabilities that enable these attacks.