Security (Tool: in-toto)

Lesson 1: Securing the DevOps Toolchain

Overview

What is Software supply chain?

A software supply chain extends the notion of a supply chain to software and system delivery. There are several steps from the point a developer commits a piece of code to a software actually shipped to end user. These steps usually includes:

Code commit—> Test—> Build —> Package—> Ship

At each steps several tools are used to mange the tasks. For example Git is used for version control, Gradle / maven are used as build tools etc.

Please watch the following video:

Securing the DevOps Toolchain
(The slides for this presentation.)

Details on Santiago's project are here.

Why do we need to secure software supply chain?

Each step in the supply chain is a point of vulnerability which could be exploited by the hackers to infect the software. For example:

  • Version control: there could be commits in the version control by unauthorized entity.
  • Test cases: certain test cases my be exploited to refrain the system from ensuring the security of software
  • Package: An unauthorized entity could package the older version of code. This could refrain millions of users from getting the latest patch of security update that was actually committed by the developer.

How to protect software supply chain?

There are several mechanism available to protect each aspect of software supply chain. For example:

  • We can enable signed commits for version control. By doing so so other people can verify that your work comes from a trusted source.
  • Packages should also be signed, should have expiration dates etc to maintain the authenticity of the package

Below are some good articles on securing the software supply chain.

How to secure your software supply chain.

Commit signature verification on Github.

Although parts of the supply chain pipeline could be secured but to completely eliminate the threat we need to secure the complete software supply chain.

As one rightly said “The chain is as strongest as its' weakest link."

This is where In-Toto help us.

Lesson 2: Some types of attacks

SQL Injection

"A SQL Injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert /Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands."
-www.owasp.org

Cross-Site Scripting (XSS)

"Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. XSS can be used by an attacker to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML that site. These scripts can even rewrite the content of the HTML page."
-www.owasp.org

Cross-Site Request Forgery (CSRF)

"Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application."
-www.owasp.org

Command Injection

"Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation."
-www.owasp.org

Web Shell

"A web shell is a script that can be uploaded to a web server to enable remote administration of the machine. Infected web servers can be either Internet-facing or internal to the network, where the web shell is used to pivot further to internal hosts."
-www.us-cert.gov

Path Traversal

"A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. It should be noted that access to files is limited by system operational access control (such as in the case of locked or in-use files on the Microsoft Windows operating system)."
-www.owasp.org

XML External Entity

"An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts."
-www.owasp.org

Insecure Deserialization

"Insecure Deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application, inflict a denial of service (DoS) attack, or even execute arbitrary code upon it being deserialized. Web applications make use of serialization and deserialization on a regular basis and most programming languages even provide native features to serialize data (especially into common formats like JSON and XML). It’s frequently possible for an attacker to abuse these deserialization features when the application is deserializing untrusted data which the attacker controls. Successful insecure deserialization attacks could allow an attacker to carry out denial-of-service (DoS) attacks, authentication bypasses, and remote code execution attacks."
-www.acunetix.com

Cloud Security

Delivering IT services via the Cloud be is a time saver, but it has a downside: the security of those services. Clouds provide these services by relying on virtualization technology. While virtualization reduces some security risks, others are increased because the attack surface in a cloud service is greater. The risks can be broadly categorised into hypervisor security, network security, data security (in transit and at rest), security of monitoring and incident response.

Lesson 3: Getting started with In-Toto

What is In-Toto ?

A software supply chain is the series of steps performed when writing, testing, packaging, and distributing software. A typical software supply chain is composed of multiple steps "chained" together that transform (e.g., compilation) or verify the state(e.g., linting) of the project in order to drive it to a final product.

in-Toto is designed to ensure the integrity of a software product from initiation to end-user installation. It does so by making it transparent to the user what steps were performed, by whom and in what order. As a result, with some guidance from the group creating the software, in-toto allows the user to verify if a step in the supply chain was intended to be performed, and if the step was performed by the right actor.

Setting up in-Toto

Here is the link to in-Toto demo page. The documentation is a step by step guide to show how a software supply chain could be secured using in-Toto plugin. Here is a brief description of what in-Toto does. Consider there are 3 people, Alice (Project owner), Bob (developer), Carl (Packages the product). In this software supply chain layout, we have Alice, who is the project owner that creates the layout using her private Key, Bob, who clones the project's repo and performs some pre-packaging editing (update version number), and Carl, who uses tar to package the project sources into a tarball, which together with the in-toto metadata composes the final product that will eventually be installed and verified by the end user. All of them have their own RSA Keys. Every time anyone makes a change it gets stored in metadata and user signs it with their respective keys. In the end when product is ready to be shipped in-Toto checks for the authenticity of the product. It considers the following parameters:

  • the layout has not expired
  • was signed with Alice’s private key,and that according to the definitions in the layout.
  • each step was performed and signed by the authorized functionary
  • the recorded materials and products follow the artifact rules
  • the inspection untar finds what it expects.

Now consider carl makes some change to the source code before packaging the software. In this case the verification check will fail as carl was not authorized to change any file but was only authorized to package the software defined in project layout.

Other Readings
  • An introduction to DevSecOps or rugged DevOps
    Rugged DevOps is the practice of shifting Security left. Security teams can introduce security much earlier in the development process. This is contrary to the standard approach where security practices of code analysis and vulnerability testing is placed just before the application is deployed into production.
  • DevSecOps: Including Security in Software Life cycle
    Introducing security practices earlier in the software engineering will enable developers to always think of security while developing their application. This will also enable them to come up with creative solutions for enabling security in their applications.
  • DevOps: A Holy Grail for Security?
    DevOps provides a method to have the concept of "Security by Design" integrated into the software engineering lifecycle from the start. It also helps keep security balanced with business objectives.
  • DevOps:Performing Penetration Testing on Web Based Application to find Vulnerabilities
    Performing a Automated/Manual penetration testing in SDLC can help to find vulnerability at early stage of development and reduce the threat to the system. Its good to work in tandem with penetration testing team to build a robust security posture.
  • DevOps: Performing a Network Penetration Testing
    Performing a Network or Infrastructure based penetration testing helps to identify the weak links inside the network components such as Servers, it also detects presence/absence of firewalls, NIDS/HIDS, vulnerable ports and services running on them. The early detection and mitigation of these vulnerabilities can help an organisation to build a robust and secure infrastructure. NMAP is an important tools to scan ports and find vulnerable services running on a server.
  • DevOps: Secure Coding Practice
    Enforcing a secure coding practice makes a programme/application resistant to malicious attackers or potentially malicious programmes. Implementing such practices in DevOps can help to build a robust security posture right from the beginning. This link enumerates top 10 best practice which any organisation following a devops practice should follow.
  • DevOps: 5 best practices for integrating security into your DevOps
    These five best practice can help to integrate security features in SDLC within DevOps practice. It entails fast and efficient way to cultivate security and has an edge over traditional way of implementing security.
  • DevOps: Cloud Security in DevOps
    Cloud security is paramount in DevOps culture since most of the organisation is preferring to host off-premises services. This book provides the best way to provide security at SaaS,IaaS,PaaS services.
  • DevOps: Misconfiguration and Security Threat in IaaS cloud
    Various problems affecting the cloud are insecure interface APIs, shared resources, data breaches, malicious insiders, and misconfiguration issues. The potential attack vectors could be storage enumeration attack, link swap attacks, leaked access tokens, Key management and legal concerns. Deploying mitigation techniques like second factor authentication, encrypted key management, Logging, Audits can help to reduce the risk.
  • Cloud Security Solution
    Few of the security solution infrastructure can be deployed in cloud environment to stop attacks like DDoS, web application attack can without reducing performance. Akamai Intelligent perform can be instrumental into threat intelligence to detect latest threats and act as a expertise to adapt to shifting and new tactics.
Lesson 4: Securing passwords and secrets in Git (or any other shared repository)

Overview
What happens when only few members of a team sharing a Git repo require passwords or keys to access sensitive files or services? It becomes inefficient to share these passwords personally or individually. Storing them openly in Git is not feasible as well, as every member sharing their repo will then gain access to these items.
To deal with this issue several libraries are available that encrypt these passowrds when pushing them onto git and only authorized people will be able to decrypt it. One of these libraries are git-crypt.

Setting up and Using Git-crypt

Setup git-crypt from this link: https://www.agwa.name/projects/git-crypt/downloads/git-crypt-0.6.0.tar.gz

Then run the following:
cd git-crypt-0.6.0
make
make install

Running git-crypt in a git repo
cd repo
git-crypt init

Specify files to encrypt by creating a .gitattributes file in the repository, with content like this:
secretFileName filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt

To encrypt a repo with your own key
git-crypt export-key /path/to/keyfile
After cloning a repository with encrypted files, unlock with
git-crypt unlock /path/to/keyfile

For more detailed information: https://www.agwa.name/projects/git-crypt/

Quiz

    There is no quiz available for this module.