Forem: Arafet Ben Kilani

Understanding SDLC and How Security Plays Into it

Arafet Ben Kilani — Tue, 20 Feb 2024 09:28:44 +0000

General Introduction
Overview of SDLC
Diving Deeper Into Each Phase
1. Requirement Analysis
2. Design
3. Development
4. Testing
5. Operations
The Importance of Security in SDLC
Conclusion

General Introduction

Welcome to the kickoff of my series titled "Secure Software/System Development Lifecycle" or SSDLC for short, where I will take you with me on a journey to explore what SSDLC is all about and why it's crucial for creating safe and robust software.

In this first article, we'll focus on the fundamental pillars of SDLC and how security plays into it.

Let's get started!

Overview of SDLC

The SDLC consists of several distinct phases. There are some variations to this but generally we have the following five phases.

Requirement Analysis : This is where we gather all the requirements from the client as to what it is that they want to build.
Design : This is where we pick different technology stacks to work with and make some architectural decisions.
Development / Implementation : This is the fun phase where we actually write code.
Testing : This is where we take the code and run some tests on it to make sure that it :
- Works (obviously !)
- Secure (Very important!)
- Meets the client's requirements.
Operations / Evolution : This is where we deploy the tested code to production environments and maintain it by going through the whole cycle again each time a bugfix or new feature is added.

Diving Deeper Into Each Phase

Let's start by uncovering the details of the Requirement Analysis (RA) phase.

Requirement Analysis

In this phase, our job involves engaging in discussions with the client to understand their project requirements and determine what they aim to build. The process generally will go like this :

Get a high-level overview of the requirements and goals
Conduct requirement analysis to make sure you understand what those requirements are.
Have an agreement with the client to make sure what they want is being captured.

⚠️ Often, clients know what they want but do not know how.

Prioritization of requirements (Differentiate between the ones that the client wants vs the ones that are nice to have).
Allocating resources ( budget, human resources) to make sure the work gets done.

Design

In this phase, the high-level system requirements previously gathered are translated into a detailed blueprint for the software solution.
It typically involves the following parts:

Architectural Design : includes system architecture, modules, and their relationships.
Data Design : includes data model and database structure necessary for the application.
UI/UX : Planning the user interface, including how users will interact with the system.

You'll want to make sure to document those design implementations to serve as a guide for the developers during the development phase.

Development

This is where the developers sit down and translate the detailed design documents into executable code that hopefully works!.

Testing

The primary goal of the testing phase is to identify and fix defects or bugs in the software to deliver a high-quality product.

There are several ways of testing code.

Unit Testing

This is the process of testing individual units of code, such as functions or classes to verify that each unit of the software performs as designed and to catch and fix any defects or errors early in the development cycle.

Integration Testing

This is focused on verifying the interactions and communication between different components, modules of a software system to discover and pinpoint defects or issues that may emerge during the combination and interaction of various components.

Integration Testing helps uncover errors such as incompatible interfaces, incorrect data transfers, communication failures and so on.

End-to-End Testing

End-to-end Testing verifies that the software works correctly from the beginning to the end of a particular user flow. It replicates expected user behavior and various usage scenarios to ensure that the software works as a whole. The goal of this form of software testing is to simulate and validate the user experience (UX) from start to finish. The key here is the UX since these tests are designed to catch any bug that any end user of the app could encounter beforehand.

Another key point to note is that End-to-End Testing can be carried out either manually or automated using specialized testing frameworks and tools such as :

⚠️ It's important to highlight that there are specific tests dedicated to security, forming a pivotal aspect of the upcoming articles in this serie.

Operations / Evolution

Once the software has passed testing and is deemed ready for release it gets moved from the development/staging environment to the production environment where it will be used by end-users. Once that is done and the software is in active use, this phase focuses on maintaining and evolving the software to meet changing requirements, address issues, and enhance its functionality over time.

Key activities during the operations/evolution phase include:

Monitoring and Support : This includes tracking performance, identifying potential issues, and providing support to end-users.
User Feedback : This is essential for understanding how well the software meets user needs. This feedback can inform future updates and improvements.
Updates and Upgrades : This could involve adding new features, improving existing ones, or incorporating security patches.

To summarize, so far we've seen a comprehensive overview of the Software Development Life Cycle (SDLC), encompassing key phases such as Requirements Analysis, Design, Development, Testing and Operations.

Now we are ready to move to the next chapter where we will delve into the critical aspect of security within the SDLC.

The Importance of Security in SDLC

Security in Software Development Life Cycle (SDLC) is crucial for creating robust, secure software applications.

Here are some key reasons highlighting the importance of security in SDLC:

Cost-Efficiency : This is the main motive behind identifying and addressing security issues early in the development process as fixing vulnerabilities during the design or coding phase is often less expensive than fixing them in production.
Risk Mitigation : Identifying vulnerabilities and implementing security measures during development reduces the likelihood of security incidents and data breaches during the application's lifecycle.
Reputation Management : Security breaches can significantly damage an organization's reputation. By prioritizing security in SDLC, companies demonstrate a commitment to protecting user data and building trust with customers, clients, and partners.

To implement security in SDLC, we focus on incorporating existing security frameworks, standards, and practices such as OWASP,NIST and DevSecOps.

Throughout this series, we will extensively explore these frameworks and intertwine their principles into our discussions.

Conclusion

In conclusion, the SDLC provides a structured framework for planning, designing, developing, testing, deploying, and maintaining software. Embedding security practices at each phase is not only essential but also fundamental in ensuring the creation of robust, resilient, and secure software systems.

Stay tuned for upcoming articles within this series as we delve deeper into SSDLC

Gitops - Infra As Code Done Right

Arafet Ben Kilani — Sat, 09 Sep 2023 17:07:05 +0000

Introduction
The Wrong Way of Doing IAC
Benefits of GitOps for IAC
1. Why Git ?
2. Gitops Workflow Explained
3. Automation and Deployment Processes
4. Easy Rollback
Conclusion

Introduction

In today's fast-paced tech world, efficiently handling infrastructure while maintaining stability and security can be a real challenge.
But what if I told you there's a way to make this process smoother and more collaborative?
GitOps a methodology that merges the power of version control, git workflows and automation with infra as code.
In this article, I will try to uncover how GitOps can revolutionize the way you handle infrastructure as a developer or operations professional.

Let's Get Started !

The Wrong Way of Doing IAC

Before we dive into gitops, we need to know the need behind it and why doing IAC in a way other than gitops is problematic!

Picture this : instead of the tedious and error-prone manual setup of a Kubernetes cluster, you are harnessing the power of Infrastructure as Code (IAC) to define the deployment environment as code with Terraform, Ansible configurations, and Kubernetes manifests as your tools of choice for example.

So you have a bunch of yaml files and other configuration files that describe your infrastructure, your plateform and it's configuration.

Bad Practice n°1 :

Storing them on local machine and not in a git repo!

-> No team collaboration and code reviews!

Bad Practice n°2 :

Storing the config files in a git repo where everyone on the team has access to it but no Review/Approval process!

-> No pull/merge requests -> Commiting directly to main branch

And by consequences no automated tests to test the code changes

-> Break something in the infrastructure or the app environment making it instable.

Bad Practice n°3 :

Updating the infrastructure and the app environment manually!

-> Everyone on the team has access to infrastructure to apply changes from their local machines making it hard to trace who executed what and when.

-> Find mistakes only once applied.

So as you see even though we are taking advantage of describing infrastructure as code which already has alot of benefits, our process is still mostly manual and inefficient. And that's where the gitops concept comes into practice to treat Infrastructure As Code the same as Application Code

Benefits of GitOps for IAC

Let's start first by discussing why Git ?

1. Why Git ?

First of all, Git provides robust version control capabilities, allowing you to track changes to your infrastructure code over time. This history is essential for collaboration and rollbacks.

Developers and operations professionals are already familiar with it, making it a convenient choice.

2. Gitops Workflow Explained

In a GitOps workflow, there is a dedicated Git repository for the Infrastructure as Code project, coupled with an associated DevOps pipeline. Let's break down the fundamental components of a typical GitOps workflow:

Establish a central Git repository that hold the Infrastructure as Code configuration files.
Create pull/merge requests to make changes and collaborate before pushing back to the main branch of the repository.
Trigger a CI pipeline to validate configuration files, and perform automated tests.
Review and approve the changes to ensure that the changes are well tested before being applied in an environment.
Trigger a CD pipeline for the continuous deployment of the infrastructure.

=> This approach will improve the quality of infrastructure and it's configuration where multiple people collaborate on the changes and things gets tested before applied.

3. Automation and Deployment Processes

Now we said that once the changes are merged into the main branch, they will be automatically applied to the infrastructure through the CD pipeline.

In gitops we have two ways to apply these changes :

Pull Deployment

In this model there is an agent installed in the deployment environment like k8s cluster that is actively pulling the changes from the git repository itself.

The agent regulary monitors and compares desired state with actual state present in the environment where its running, if it sees that there is a difference it will pull and applies the changes to get the environment to the desired state defined in the repository.

Mostly applicable in the context of Kubernetes and containerized environments.

Popular Examples : Argocd, Fluxcd

Push Deployment

This is the traditional way that we know.
In this model we explicitly define jobs in the application CI/CD pipeline that will execute commands to update the infrastructure or deploy the new application version to the deployment environment

4. Easy Rollback

Now that we know that changes in the git repository are automatically synced with the deployment environment.
We can easily leverage the power of git in tracking the history of changes to rollback to any previous state by simply using git revert

Conclusion

In conclusion, Gitops is a powerful approach that brings together the principles of version control, git workflow and automation to make IAC or more generally xAC smoother, more stable and secure.

AWS Networking Fundamentals

Arafet Ben Kilani — Tue, 04 Jul 2023 21:57:25 +0000

Introduction

Welcome to the world of AWS, In this article I will take you on a journey to explore the fundamentals of networking within AWS. Whether you're preparing for the AWS Certified Solutions Architect exam or simply curious about how AWS manages networking,then this article will provide you with valuable insights.Throughout our journey we will touch upon essential topics such as Virtual Private Clouds (VPCs), subnets, security groups, internet gateways and so many more.

Let's Get Started !

Virtual Private Cloud (VPC)

Ever wondered how millions of cloud users worldwide can utilize the same hardware for their applications without encountering resource conflicts?

Well the answer is vpc , essentially it's a private network within the cloud that isolate your cloud resources from other aws customers.

It is a regional service (Tied to a single region)

By default, each region gonna have a default vpc initially created by aws but we can create up to 4 additional vpcs per region which total to 5

Subnets

Subnets as their name suggests are logical partitions within a vpc created at the availability zone level which means a subnet can only exist within a single AZ.

Can create up to 200 subnets per vpc.

There are two type of subnets :

 - Public Subnet : resources that live here have access 
                   to the internet.

 - Private Subnet : resources that live here can't access 
                    the internet directly.

IP Adressing

Each vpc require a range/pool of private ip addresses called a cidr block, an example would look like this 10.0.0.0/24

The /24 part called suffix identifies the network part of the ip address, now without entering the details of how the ipv4 address scheme work the only thing we need to know is choosing the suffix depends on the size of infra we wanna build for example a /24 cidr block would provide us with 256 ip addresses, the first 5 addresses are reserved which leaves us with 251 ips or in other words can only have 251 running machines inside the vpc.

If you want me to write an article explaining how ipv4 and CIDR blocks work tell me in the comments bellow

In the meanwhile check this user guide provided by amazon on how to choose a cidr block for a vpc

VPC CIDR blocks

Each subnet in the vpc needs also a cidr block that is a subset of the vpc's cidr block.We can achieve this by taking the vpc cidr block and subnetting it even further using different techniques that are out of the scope for this article.

There are 3 types of ip addresses in aws

  - Public : Identifies resources on the internet 
             Temporary (changes everytime we stop/start 
                        the instance).

  - Private : Identifies resources in the vpc and it's 
              permanent unless the instance is terminated

  - Elastic : A static public ip address (permanente).
              Created seperately and can be attached to 
              an ec2 instance.
              Aws only charge money when it's not in use.

Internet Gateway

It is a VPC component that allows communication between your VPC and the internet as simple as that.

Route Table

A table that contains the different routes in/out a subnet.

By default, aws creates a route table called main route table in every main vpc (default vpc /region) and associate it with all default subnets in the vpc (in every AZ aws creates a default subnet )

So to enable access to or from the internet for instances in a subnet in a VPC using an internet gateway, you must do the following :

Create an internet gateway and attach it to your VPC.
Add a route to your subnet's route table that directs internet-bound traffic to the internet gateway.
Ensure that your network access control lists and security group rules allow the desired internet traffic (we will get to this later in the article when discussing security groups and Nacls )

Overall, we will have something like this at the end

Nat Gateways

What if you want to make some updates to an ec2 instance that lives in a private subnet ? how can you access the internet to pull the updates ?

Well nat gateways is there for the rescue, it's a managed solution provided by aws that allows instances in a private subnet to connect to services outside your VPC such as the internet or other isolated vpcs.

There are two types :

Public (default) : Instances in private subnets can
connect to the internet, but cannot receive connections
from it.
Must be created in a public subnet
Must associate an elastic IP address with the NAT
gateway at creation.
Private : Instances in private subnets can connect to
other VPCs or your on-premises network through it.

In most cases we use public Nat gateways.

The only thing left to do is to update the route table associated with the private subnet to be able to direct internet-bound traffic to the Nat gateway.

Security groups and Nacls

They are both firewalls

Security groups are stateful and controls inbound/outbound traffic at the instance level.

By default all outbound traffic is allowed and all inbound traffic is denied

Stateful means that if a connection to/from the instance is made in one direction (Passed the firewall rule) then the reply in the other direction is automatically allowed.
wich means requests have to pass the firewall rules only once.

Example of an inbound rule

Example of an outbound rule

Some notes about security groups :

Specific to a region and a vpc.
Source and Destination can be a cidr or another security group

Nacls are stateless and controls inbound/outbound traffic at the subnet level.

By default it allows all traffic from anywhere.

Example : Let's say we want to deny http traffic on port 80

Rules are evaluated by number (lowest number evaluated first)

The default rule designated by (*) can't be deleted and it's always evaluated last and catches anything that didn't match prior rules.

An advantage of Nacls over security groups is that they give us the ability to define deny rules which allows us to block a specific ip addresses from reaching resources on a specific subnet.

Bastion Hosts

Now imagine that we want to ssh into an ec2 instance that lives in a private subnet to perform some configurations.

Answer : Bastion hosts also called jump hosts.

They are regular ec2 instances that live in a public subnet and we use them as a intermediary for ssh'ing into an instance within a private subnet.

Vpc Endpoints

In simple words they allow instances in a vpc to reach 'Paas' services like S3 and Dynamodb through aws's private network instead of going through the internet.
Can be used for additional layer of security.

There are two type of endpoints :

Gateway : Allows connections to S3 and DynamoDB only.
Interface : Allow connections to all other aws services.

Services that are managed by aws like S3 , DynamoDB etc do not belong to a vpc.
The only way for resources within our vpc to reach these services is through the internet or through vpc endpoints.

Vpc Peering And Transit Gateways

So far we talked about how vpcs are isolated from each other which means there is no network reachability between them.

How can we make two or more vpcs communicate with each other through aws's private network.

We have two ways to do it :

Vpc peering : We create a peering connection that allow two vpcs to behave as a single network under the condition that these two vpcs cannot have overlapping cidr ranges.

We can peer two vpcs within same account or accross multiple aws accounts

Not transitive.

We also have to update the routing tables in each vpc to allow traffic back and forth.

Transit Gateway : Allow us to connect two or more vpcs together and unlike vpc peering they are transitive.

They also can peer other transit gateways.

At the moment this is the only service that support multicast routing.

Multicast : means delivering single stream of data to multiple recieving instances simultaneously.

Site-to-Site Vpn

Suppose we want to connect a on-premise cloud to aws

One option for doing this is through vpn

On the customer side you'll need a customer gateway managed on-premise and on the Aws side you'll need a virtual private gateway.

In the subnet route tables we need to enable route propagation and in the security groups of the ec2 instances we need to allow inbound icmp messages in order for this to work.

Even though the traffic is encrypted it's still going through the public internet.

So if we want maximum security then we can use direct connect.

Direct Connect

This offers a dedicated physical connection (using optic fibers) from on-premise to aws.

More expensive and takes longer to setup.

Conclusion

In this article I tried to provide an overview of networking fundamentals in AWS. It is important to recognize that a comprehensive understanding of AWS networking requires a deeper exploration beyond the scope of a single article.
As with any technical subject, hands-on experience and continuous learning are crucial.

Alright that concludes our journey today thank you for your time
If you have any questions don't hesitate to ask in the comment section.

Have a nice day !

Podman : An Alternative To Docker ?

Arafet Ben Kilani — Mon, 19 Jun 2023 21:48:17 +0000

While docker has undoubtedly revolutionized the way we develop, deploy, and run applications, it's worth exploring what sets Podman (Pod Manager) apart and why you may want to start using it instead.
In this article, we'll dive into the core features of podman assuming that everyone is already familiar with Docker.

Let's Start!

What is Podman?

In simple words, Podman is an open-source container and pod manager.

Similar to docker, it allows you to create, start, stop, and delete OCI containers, as well as manage container images but also supports pods as part of its feature set wich means you can create and manage pods just like you would with Kubernetes.

But wait OCI Containers ?

OCI (Open Container Initiative) : is an industry-standard organization that aims to create set of rules (specifications and standards) that ensure containers work consistently across different platforms.

So what does this mean ?

It means that Podman's images/containers are fully compatible with docker's or any containerization technology that relies on an OCI compliant container runtime.

Great so now we know that podman is fully compatible with docker but wait it's more interesting.

Most docker users can simply alias Docker to Podman (alias docker=podman) without any problems.
This means that all docker's commands stay the same with the exception of docker swarm.

Your probably wondering what does Podman bring to the table.

Let's dive deeper!

Architecture

Can you spot the difference ?

Podman's architecture is daemonless.

Wow what is that and why are we trying to get rid of the good old docker daemon ?

Daemons are processes that run in the background of the system, they typically run continuously in the background, waiting for certain events or requests to occur.

Back to containers, Think of the docker daemon as the intermediary communicating between the user and the container itself.

Problems ?

There are few problems with using a daemon to manage containers :

Single point of failure
Once the daemon crashes, all containers do.

Requires root privileges
This makes the docker daemon an ideal target for hackers who want to gain control of your containers and infiltrate the host system.

Podman addresses the mentioned challenges by directly interacting with container registries, containers, and image storage without the need for a daemon hence the daemonless architecture.

By going rootless (not requiring root privileges), users can create, run, and manage containers without requiring processes with admin privileges reducing the security risks

The buildah utility takes the place of docker build as a container image building tool. Similarly, skopeo replaces docker push and enables the movement of container images between registries. These tools provide efficient and direct interactions with the necessary components, eliminating the need for a separate daemon in the process.

Should I re-write every dockerfile and docker-compose file to be able to use podman with my existing projects ?

Answer : Absolutley Not

Podman aims to provide a familiar developer experience by offering compatibility with docker's containerfile syntax.
Additionally, Podman introduces a similar tool called pod compose as an alternative to docker compose.
Pod compose utilizes the same syntax allowing you to define and manage multi-container applications using the same approach or even using existing "docker-compose.yml" files.

As for Docker desktop, Podman also comes with Podman desktop offering enhanced features that make it more powerful and streamlined. It offers compatibility with Docker and Kubernetes, amplifying its capabilities and delivering a smoother experience.

You can find Podman's installation guide and documentation in their official website podman.io

Conclusion

Given Podman's daemonless architecture, comparable developer experience to Docker, and the fact that both are open-source projects with thriving communities, there are no significant advantages to sticking with Docker over Podman.

Forem: Arafet Ben Kilani

Understanding SDLC and How Security Plays Into it

Table Of Contents

General Introduction

Let's get started!

Overview of SDLC

Diving Deeper Into Each Phase

Requirement Analysis

Design

Development

Testing

Operations / Evolution

The Importance of Security in SDLC

Conclusion

Gitops - Infra As Code Done Right

Table Of Contents

Introduction

Let's Get Started !

The Wrong Way of Doing IAC

Benefits of GitOps for IAC

1. Why Git ?

2. Gitops Workflow Explained

3. Automation and Deployment Processes

4. Easy Rollback

Conclusion

AWS Networking Fundamentals

Podman : An Alternative To Docker ?

What is Podman?

Architecture

Conclusion