Why Docker is better than Virtual Machine?
Microservices for Modernizing Legacy Applications
How to create CI/CD Pipeline using CircleCI
Codefresh vs. Jenkins: A quick comparison
DevOps strategies to boost your security
DevOps provides an environment with great potential to enhance security. Practices such as collaboration, continuous testing, automation better feedback loops, provides an opportunity to integrate security as a component of the DevOps processes.
Mostly, a wide range of security flaws and risks exist in the cloud environment, containers, and other resources developers rely on when making applications. This includes the third-party code, tools, networks, and other components of the development systems. Without proper tools, control, and protection, these areas can lead to unstable and insecure applications.
Some factors that increase vulnerabilities include:
- Wrong configurations and weakness in containers
- Insecure in-house and third-party code, privilege exposures, etc.
- Security flaws in the scripts or CI/CD tools
- Malicious insiders
- Insecure infrastructure and employee behavior.
Many common DevOps practices inherently lend themselves to providing a development and delivery pipeline that can improve your overall security posture.
Three biggest risks to IT security are as follows:
- Human error
- Lack of process
- External threats
DevOps can positively impact all three of these major risk factors, without negatively impacting the stability or reliability of the core business network.
Best DevOps practices to boost your security
Here, is a list of the top five DevOps practices and tooling that can help boost overall security when incorporated directly into your end-to-end continuous integration/continuous delivery (CI/CD) pipeline:
- Collaboration
- Security test automation
- Configuration and patch management
- Continuous monitoring
- Identity management
Collaboration and understanding your security requirements
Many of us are required to adopt a security policy. It may be in the form of a corporate security policy, a customer security policy, or a set of compliance standards (ex. SOX, HIPAA, etc). Even if you are not mandated to use a specific policy or regulating standard, we all still want to ensure we follow the best practices in securing our systems and applications. The key is to identify your sources of security requirements information and, collaborate early so they can be incorporated into the overall solution.
Security test automation
Whether you are building a brand new solution or upgrading an existing solution, there likely are several security considerations to integrate. Due to iterative agile development, handling all security at once in a “big bang” approach likely will result in project delays. To be certain that projects keep moving, a layered approach often can be helpful to ensure you are continuously building additional security layers into your pipeline as you progress from development to a live product. Security test automation can ensure you have quality gates throughout your deployment pipeline giving immediate feedback to stakeholders on a security standpoint and allowing for quick remediation early in the pipeline.
Configuration management
In traditional development, servers/instances are equipped and developers are able to work on the systems. To make sure servers are equipped and managed using consistent, repeatable, and reliable patterns it’s critical to ensure you have a strategy for configuration management. The key is to be certain you can reliably guarantee and manage consistent settings across your environments.
Patch management
Similar to the concerns with configuration management, you need to make sure you have a method to quickly and reliably patch your systems. Missing patches are a common cause of exploited vulnerabilities including malware attacks. Being able to swiftly deliver a patch across a large number of systems can drastically reduce your overall security exposures.
Continuous monitoring
Make certain you have monitoring in place across all environments with transparent feedback is important so it can alert you quickly of potential breaches or security issues. It is important to identify your monitoring needs across the infrastructure and application and then take benefits of some of the tooling that exists to quickly identify, isolate, and remediate potential issues before they become vulnerable. Most of your monitoring strategy also should include the ability to automatically collect and analyze logs. The analysis of running logs can help identify exposures quickly and compliance activities can become extremely expensive if they are not automated early.
Identity management
DevOps strategies allow us to integrate early with security experts which increase the level of security tests and automation to enforce quality gates for security and provide better mechanisms for ongoing security management and compliance activities.
Conclusion
Incorporating security practices into your DevOps processes boosts in creating an effective security layer for the environment and applications. This, in the future, ensures security and compliance in a more proactive and efficient way.
Is CNSP the future of software development?
Application development methodologies or say SDLC are moving away from the traditional “waterfall” or “V” model towards more agile continuous integration delivery (CI/CD) processes with the end-to-end automation. This new approach brings a multitude of benefits, such as quick release time to market and faster delivery, but it also introduces security challenges since traditional security methodologies weren’t designed to address these modern application workflows.
As developer teams adopt cloud-native technologies, security teams find themselves scrambling to keep up. Minimal prevention controls, lack of visibility, and tools that lack automation yield incomplete security analytics. All of these things increase the risk of compromise and the likelihood of successful breaches in cloud environments. Meanwhile, the demand for an entirely new approach to security emerges. Enter cloud-native security platforms.
Before we dive into what is a cloud-native security platform CNSP, let’s first understand what “cloud-native” actually means.
What Does ‘Cloud-Native’ Mean?
The term “cloud-native” refers to an approach to building and running applications that takes full advantage of a cloud computing delivery model instead of an on-premises data center.
This process takes the best of what cloud has to offer
- Scalability
- Deployability
- Manageability
- Limitless on-demand compute power
and applies these principles to software development, combined with CI/CD automation, to radically increase productivity, business agility, and cost savings.
Cloud-native architectures are made up of cloud services, such as containers, serverless security, platform as a service (PaaS), and microservices. These services are loosely coupled, meaning they are not hardwired to any infrastructure components, allowing developers to make changes frequently without affecting other pieces of the application or other team member’s projects – all across technology boundaries, such as public, private and multi-cloud deployments.
In short, “cloud-native security” refers to a methodology of software development that is essentially designed for cloud delivery and epitomizes all the benefits of the cloud by nature.
The 4C’s of Cloud-Native Security
Let’s start with a diagram that may help you understand how you can think about security in layers.
Note: This layered approach augments the defense-in-depth approach to security, which is widely regarded as a best practice for securing software systems. The 4C’s are Cloud, Clusters, Containers, and Code.
As you can see from the above figure, each one of the 4C’s depend on the security of the squares in which they fit. It is nearly impossible to safeguard against poor security standards in Cloud, Containers, and Code by only addressing security at the code level. However, when these areas are dealt with appropriately, then adding security to your code augments an already strong base.
The Beginnings of Cloud-Native Security
As more organizations have embraced DevOps and developer teams have begun to update their application development pipelines, Security teams quickly realized their tools were ill-suited for the developer-driven, API-centric, infrastructure-agnostic patterns of cloud-native security. As a result, cloud-native security platform products began to hit the market. These products on their own, they could not collect enough information to accurately understand or report on the risks across cloud-native environments. They were each engineered to address one part of the problem or one segment of the software stack. This forced security teams to juggle multiple tools and vendors, which increased cost, complexity, and risk in addition to creating blind spots where the tools overlapped but didn’t integrate.
Enter Cloud-Native Security Platforms
Solving this problem requires a unified platform approach that can envelop the entire CI/CD lifecycle and integrate with the DevOps workflow. Just as cloud-native approaches have fundamentally changed how cloud is used, CNSP is fundamentally restructuring how the cloud is secured.
Cloud-native security platform shares context about infrastructure, PaaS, users, development platforms, data, and application workloads across platform components to enhance security. They also:
- Provide unified visibility for SecOps and DevOps teams.
- Dispatch an integrated set of capabilities to respond to threats and protect cloud-native applications.
- Automate the remediation of misconfigurations and vulnerabilities consistently across the entire build deploy run lifecycle.
Cloud-Native Security Platform Future
In the past, organizations that wanted to embrace new compute options were unendurable by the need to buy more security products to support those options. Stitching together disparate solutions in an attempt to enforce consistent policies across technology boundaries became more of a problem than a solution.
Cloud-Native security platform, however, provides coverage across the continuum of compute options, multi-cloud, and the application development lifecycle. This allows organizations to choose the right to compute options for any given workload, granting them freedom without worry over how to integrate solutions for security. CNSP epitomizes the benefits of a cloud-native strategy, enabling agility, flexibility, and digital transformation.
Shift Left Security – An Approach in Application Security
Since the beginning of modern computing, security has largely been separated from software development. The latest vulnerability research confirms that over the past five years, out of all published vulnerabilities, 76% were from applications. Given this radical shift in attacker focus, it’s time to implant security with development. The best approach to get this done is to implement a shift-left security strategy.
“Only 20% of organizations following DevOps practices consistently integrate security into the development process”
Source:HPE /True State of Application Security & DevOps
“Only 15% of organizations can remediate security vulnerabilities or address compliance violations as they arise“
Source: Chef| 2017 Community Survey
What is shift-left security?
Moving security practices left into the software development lifecycle with the goal of shifting from a reactive to a proactive security posture.
In the simple definition, “shift left” security is moving security to the earliest possible point in the development process. Modern CI/CD typically involves an eight-step process as shown in the figure below. Many security teams only become involved in the concluding steps of operations and monitoring. Consider that shift-left security is good for reducing not only security risk but also cost. Addressing security issues in design was six times cheaper than during implementation but the same security issues addressed during testing could be 10 times costlier.
Step 1: Define your shift-left security strategy
The first step of any journey is to define where you plan to go. It is important to define what shift-left means in your organization. This is about painting the most evocative picture possible for your teams so they know what success looks like. Key items to include in this document plan are vision, ownership/responsibility, milestones, and metrics. Expect the strategy document to mature over time and don’t spend too much time trying to perfect it. Iteration over time is essential.
Step 2: Understand where & how software is created in your organization
Perhaps one of the most challenging aspects of shifting security left is first getting a hold on how and where software is created in your organization. Depending on the size of your company, this could run the gamut from straightforward to extremely challenging. This step is critical because the end result is what allows the security team to understand where they can actually move security closer to development. In many instances, development is outsourced to multiple vendors, which will require additional work. Small and medium-sized companies will find this step relatively straightforward but equally rewarding.
The objective of this step is to first look organization-wide and document the overall flow of software in your company. Medium to large organizations will want to start at large-scale level and then drill into individual business units. It is certain that each business unit will have its own software development process and tools. Key items to identify in this process include who is developing code (people), how it flows from the development environment to production (process), and which systems they are using to enable the process (technology). This may also be referred to as the CI/CD toolchain. Undoubtedly, much of your software development is being done in the public cloud.
Step 3: Identify and implement security quality guardrails
Quality assurance and quality control has always been part of the software development lifecycle. However, software quality has not historically included security. Every step of the software development process is an opportunity to give feedback and look for security issues. The most effective security teams start small and automate at every stage of SDLC.
Step 4: Assess and continuously train development teams in secure coding
Developers undoubtedly know how to code, but do they know how to do it securely? Most of the time-shifting security left is to ensure that those who do the majority of your coding create secure code in the first place. This is problematic to do if you have no objective measure of where their skills stand today and no plan to improve them continually over time. Given that in one survey, 19% of developers said they were unfamiliar with the OWASP Top 10, this is an area that should not be overlooked. As per a recent survey published by DevOps service provider GitLab, which found that 70% of programmers are expected to write secure code, but only 25% think their organization’s security practices are “good.” If only 25% of developers feel this way, security teams have a lot of work to do in this area.
What shift-left security looks like
Let’s look at these two scenarios below where we have simplified development into build, deploy, and run phases.
In Scenario 1, development starts without security. Software quality is only checked during runtime. This frequently results in an uneasy conversation between security and development when vulnerabilities are found.
Scenario 1
In Scenario 2, however, security teams have invested the time to understand the development process in their organization. They have also taken the time to merge security processes and tools in the CI/CD pipeline, resulting in automated security quality guardrails.
Scenario 2
Conclusion
Utilizing these four steps above will put your organization on a solid path towards not only shifting security left but making security equal with development. As your organization moves towards shift left as part of its cloud journey, it’s critical that security controls be automated at every stage of the software development life cycle. Neova Solutions empowers security teams to do exactly that by securing DevOps and your CI/CD pipeline.
AWS CIS Compliance Test: A Cloud Security Requirement
What is CIS Benchmarks ?
Center for Internet Security (CIS) Benchmark for AWS is the best practices & recommendations for the secure configuration of AWS Accounts. CIS Benchmarks are the only consensus-based, best-practice security configuration guides both developed and accepted by the government, industry, academia, and business. The Benchmark recommendation document provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings. Specific Amazon Web Services in scope for this document include:
- AWS Identity and Access Management (IAM)
- AWS Config
- AWS CloudTrail
- AWS CloudWatch
- AWS Simple Notification Service (SNS)
- AWS Simple Storage Service (S3)
- AWS VPC (Default)
The CIS AWS Foundation document v1.2.0 enlist 49 recommendations categorized across features into
- IAM
- Logging
- Monitoring
- Networking
How does one test for compliance with the Benchmarks ?
Manually validating each recommendation across your AWS account can be cumbersome and exhaustive. This approach may be prone to human errors and with the growing number of resources across your AWS account, it would be nearly impossible to timely test the compliance.
Automated compliance check is the only option that can timely deliver the compliance checks on your AWS account. With AWS SDKs, CLI and API’s available, any approach can be used to automate the compliance checks for CIS Benchmarks.
An Example –
Recommendation 2.3 – Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible (Scored)
Description: CloudTrail logs a record of every API call made in your AWS account. These log files are stored in an S3 bucket. It is recommended that the bucket policy, or access control list (ACL), applied to the S3 bucket that CloudTrail logs to prevent public access to the CloudTrail logs.
Manual Steps via the Management Console
1. Go to the Amazon CloudTrail console at https://console.aws.amazon.com/cloudtrail/home
2. In the API activity history pane on the left, click Trails
3. In the Trails pane, note the bucket names in the S3 bucket column
4. Go to Amazon S3 console at https://console.aws.amazon.com/s3/home
5. For each bucket noted in step 3, right-click on the bucket and click Properties
6. In the Properties pane, click the Permissions tab.
7. The tab shows a list of grants, one row per grant, in the bucket ACL. Each row identifies the grantee and the permissions granted.
8. Ensure no rows exist that have the Grantee set to Everyone or the Grantee set to Any Authenticated User.
9. If the Edit bucket policy button is present, click it to review the bucket policy.
10. Ensure the policy does not contain a Statement having an Effect set to Allow and a Principal set to “*” or {“AWS” : “*”}
Automated Approach using CLI –
1. Get the name of the S3 bucket that CloudTrail is logging to:
aws cloudtrail describe-trails --query 'trailList[*].S3BucketName'
2. Ensure the AllUsers principal is not granted privileges to that <bucket>:
aws s3api get-bucket-acl --bucket <s3_bucket_for_cloudtrail> --query 'Grants[?Grantee.URI== `http://acs.amazonaws.com/groups/global/AllUsers` ]'
3. Ensure the AuthenticatedUsers principal is not granted privileges to that <bucket>:
aws s3api get-bucket-acl --bucket <s3_bucket_for_cloudtrail> --query 'Grants[?Grantee.URI== `http://acs.amazonaws.com/groups/global/Authenticated Users` ]'
4. Get the S3 Bucket Policy
aws s3api get-bucket-policy --bucket <s3_bucket_for_cloudtrail>
