MSP

The objective of Patch Management is to keep various systems within the network up to date and secure the systems from various kinds of cyber-attacks. Patch Management is the method of installing and managing the latest patches or code changes to fix security vulnerabilities on various systems within a network.

In this blog, lets deep dive into the advantage of AWS Next Generation automated patching over the Traditional Patch management.

Traditional Patch Management

Patch management is critical to the security of computers on a network. But patching is not a one-time process. The security team/ Subject Matter Expert (SME) within any organizations had to create a scheduled scan that will routinely check for missing patches, so that the team/SME can keep the computers on the network up to date.
For example, let’s get back to the good olden days on how Microsoft updates were applied to the systems using WSUS server. The team/SME had to perform a scan to find out which updates are missing from which computers. Each time there is a plan for deploying updates, the team/ SME will have to perform a new scan. Microsoft introduced WSUS server for patch management. The prerequisites were a server running Windows Server 2003 SP1 or greater, IIS 6.0 or greater, .NET 2.0 framework, and Report Viewer 2008 Redistributable 2008. Also, a dedicated team for patch management.
Demerits of Traditional Patch Management:

1. Manual Process
2. A dedicated resource/team to keep track of patches, schedule scans and updates
3. Possibility of human errors (miss out some critical security updates)
4. Decision on the patches to install and which one to ignore and what the optimum order of installation should be
5. Testing of patches before implementation requires a testing environment with spare hardware, software and SME ready adds to additional cost
   As the organizations IT Head wish is to have seamless patch management. The businesses are currently moving towards the transformation journey for continuous delivery, AWS adds incredible value towards on-demand infrastructure resources and tools to empower the Devops practices.

AWS Next Gen Patching using Systems Manager

The automated enterprise patch management tools carry out the patching process by deploying or installing agents on target instances (Windows/Linux). These agents provide a connection between the centralized patch server and the computers to be patched. With AWS System Manager, the business can install and configure the SSM agent that can update, manage, and configure the AWS resources. By using the customized SSM document (part of DevOps) Cloud Comrade can ease the intricacy for the security team by running the patch baselines in the multi accounts and multi regions.

AWS Systems Manager key features:

• Automatic deployment of operating system and software patches.
• View resource groups recent API activity, resource configuration changes, related notifications, operational alerts, software inventory, and patch compliance status.
• Centralized location where operations engineers and IT professionals can view, investigate, and resolve operational issues related to the resources and to have complete control over operations.
• Customizable key insights dashboard, providing key insights and analysis into the operational health and performance of your AWS environment.
• Secure remote management of instances at scale without logging into servers, replacing the need for bastion hosts, SSH, or remote PowerShell.
• Using session manager, the business can control which users can access each instance, including the option to provide non-root access to specified users.
• Option for auto-approve select categories of patches to be installed.
• Maintenance window for patching.
• With Systems Manager, the business can control configuration details such as server configurations, anti-virus definitions, firewall settings, and more.

In Cloud Comrade, we have strong expertise in centralized multi account and region patching using customized Systems Manager document. Connect with us to know more about AWS Next Gen Automation.

In this Cloud Computing world, organizations of all sizes continue to focus on eliminating the need for monotonous tasks and improving processes. However, many organizations still rely on using high valued resources to perform manual tasks. Not only is this a waste of time and money, but it is highly inefficient and will lead to human errors.

Traditional way of AMI:

• Manually create an AMI from the instance.
• Launch the instance for security patching and install required software’s
• Manually share the AMI to other accounts

Currently, many organizations are moving into cloud computing to scale up their business. They spin up more workloads to Amazon Web Services (AWS). But how does the team ensure when a new VM is provisioned: can be scalable, in a reliable manner, error free, with no vulnerabilities.

A golden AMI is an AMI that can be standardized through configuration, consistent security patching, and hardening. It also contains agents to approve for logging, security, and performance monitoring.

AMIs use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). The main differences between PV and HVM AMIs are the way in which they boot and whether they can take advantage of special hardware extensions for better performance. Windows AMIs are HVM AMIs.

The old saying goes: if you are doing something more than a couple of times, automate it.

Golden AMI Pipeline

This blog is about building a secured, approved Golden AMI image for providing a reliable, scalable, and approved application stack factory that increases innovation swiftness, reduces effort, and increases the confidence of Securiy team to ensure that the teams are compliant.

Automated Golden AMI Pipeline Process Flow

AMI Factory Pipeline:

1. Step 1 (optional): Subscribe to the AWS marketplace product you want to distribute 
2. Step 2: Create a cross-account role in the child account
3. Step 3: Set up the golden AMI pipeline environment
4. Step 4 (optional): Set up a compliance check in the child account(s) 
5. Step 5: Create a golden AMI
6. Step 6: Approve the golden AMI
7. Step 7: Review  the golden AMI metadata
8. Step 8 (optional): Manually trigger continuous vulnerability assessment of golden AMIs 
9. Step 9: Distribute the golden AMI to child account
10. Step 10: Decommission the golden AMI

Once you have shared the base golden AMI with development teams, they can consume the latest golden AMI in the simplest way possible, often through automation. They can customize the OS specific golden AMIs with the required software components, but also ensure that the AMIs continue to meet the organization’s requirements. 

The development teams can repeat the above process. Each team within the business can use the golden OS AMI shared by the Security team and can add their own software and produce a new golden AMI that is secured, scanned, distributed, and consumed as necessary.   

To assess different features of the golden AMI pipeline:

1. Create golden AMI and then distribute the same to a child account.
2. Manually perform a continuous vulnerability assessment of the active golden AMI.
3. Deploy an instance of a golden AMI in a governed manner.
4. Finally, decommission the golden AMI.

Cloud Comrade’s expertise in Automation can help businesses in setting up a consistent template model, which ensures consistency, secured, scalable, and reliable Golden Image pipeline.

With traditional deployment, new versions of an application are released using various tools to pull the code from a repository and push it to a production server. Once the code has been pushed, each application process is restarted manually. While this process works, it is by no means an easy process to switch from running in the development environment to the production environment.

There are various issues with this traditional deployment process, for example different environments (development work and production server), application configuration management, and replication of an application environment.

Every software deployment involves processes and practices for successful execution & deployment of the deployment. The complications also increase in an exponential manner based on the project size. The organization should build an automated pipeline to develop, test, and release the software in a manner so that the release is done in an incremental manner thereby having minimal or no impact to the project deployment.

With CI/CD pipeline, it helps the organizations automate steps in your software delivery process, such as initiating code builds, running automated tests, and deploying to a staging or production environment. Some of the benefits of CI/CD Pipeline are cost effective, easy to make real time decision, early bug recognition remove manual errors, provide standardized development feedback loops and enable fast product iterations.

In this below diagram, lets have a look at how automated AWS Code pipeline with Code Commit, Code Build and Code Deploy integrated with AWS Landing Zone for “maker” and “approver” process along with creation of workload application account using Account Vending Machine from child member account.

Code Commit is to securely store the source codes to make easier for the teams to collaborate on code in a secure and highly scalable ecosystem. CodeBuild compiles your source code, runs unit tests, and produces artifacts that are ready to deploy. CodeBuild eliminates the need to provision, manage, and scale your own build servers. S3 bucket for artifacts is also setup with the first AWS CodeCommit repository and shared across all other AWS CodeCommit and AWS CodePipeline resources. For the AWS CodeCommit, CodePipeline, and CodeBuild it’s a best practice to use CloudFormation templates that allow organizations to automate the creation of accounts and resources.

With strong expertise in Automation, Cloud Comrade has proven examples offering their clients an Automated Account Creation with AWS Service Catalog and Cloud Development Toolkit to enhance the organization’s current Landing Zone. 

The Cloud era has brought a perilous challenge of managing application secrets, encryption, and access to any resource in the Cloud. Securing and rotating secrets regularly and properly, both in the Cloud and on-premise, can have a significant challenge.

As part of traditional method, we love keeping configurations in text files, we store the database credentials or sensitive data, for example securing remote login stored in the ~/.ssh/ directory, the private key might commonly be found in a file called id_rsa, and the public key might be in a file called id_rsa.pub..Then commit, push and everything goes to the code repo.

The traditional concept has its own flaws like changing the passwords, human errors like creating a public repo, publicly available code repo etc.

Amazon Web Service’s Secrets Manager makes it effortless for organizations to store and retrieve the secrets using an API and Command Line Interface.

What is AWS Secrets Manager

AWS Secrets Manager helps you protect secrets needed to access your applications, services, and IT resources. The service enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.

API keys and secrets are difficult to handle safely, and probably something we avoid thinking about.

Benefits of AWS Secrets Manager

• Rotate secrets safely
• Manage access with fine-grained policies
• Secure and audit secrets centrally
• Pay as you go

When CI/CD pipelines moved to the public cloud, credential management did not evolve with them. AWS Secrets Manager is a comprehensive solution for secure secret storage. The organizations can define a secret just once for your whole AWS account, then we give our consumers permission to use the secrets.

Steps:

1. The database administrator creates a set of credentials on the Personnel database to use with an application called MyCustomApp(sample application created in my training account). The administrator also configures those credentials with the required permissions to access the Personnel database. 
2. The database administrator stores the credentials as a secret in Secrets Manager named MyCustomAppCreds. Secrets Manager encrypts and stores the credentials within the secret as the protected secret text. 
3. When MyCustomApp needs to access the database, the application queries Secrets Manager for the secret named MyCustomAppCreds. 
4. Secrets Manager retrieves the secret, decrypts the protected secret text, and returns it to the client application over a secureHTTPS with TLS channel. 
5. The client application parses the credentials, connection string, and any other required information from the response and then uses the information to access the database server. 

Kindly note that Secrets Manager can natively rotate credentials for supported AWS databases without requiring additional programming. However, if organizations wants to rotate the secrets for other databases or services,  Cloud Comrade has the expertise in creating custom Lambda function to define how Secrets Manager interacts with the database or service.

How to Centralize The Rotation of RDS Key Using Automation

In this example the RDS credentials on Workload Application Account will be stored in Shared Services Account (Landing Zone). The credentials will be rotated periodically.   

How to Centralize The Rotation of API Key Credentials Using Automation

In this example the API Key credentials from Application Workload Account will be stored in the Shared Services Account (Landing Zone). The credentials will be rotated periodically.   

Secrets Manager lets us manage a secret entry (name and metadata) separately from its value, and it integrates with other AWS services that we already use:

• Secret entry management: Manual (Web console, AWS CLI) or with an infrastructure management tool (Terraform, CloudFormation etc.)
• Secret value management: Manual (Web console, AWS CLI) or automatic (secret rotation Lambda function).
• Access control: AWS IAM policies (for both applications and human operators).
• Secret encryption: Amazon KMS automatically encrypts the secret value. Use either the account’s default KMS key, or a customer-managed KMS key.
• Auditing: AWS CloudTrail and CloudWatch Events.

Cloud Comrade has strong expertise in automating AWS Secrets Manager and allows you to consolidate the secrets into one place, and use them securely from Jenkins.