DevSecOps

1. By Eng Soon Cheah DevSecOps
2. Who am I ? Microsoft MVP | Trainer | Speaker MCSA : Cloud Platform MCSE : Cloud Platform and Infrastructure Co-Organizer of Malaysia Mobile .Net Developers Group Twitter : @CheahEngSoon Email : cheahengsoon@live.com.my YouTube Channel :http://bit.ly/engsoonyoutube
3. Understanding the security challenges of DevOps Engineering teams have increased autonomy More development technologies are available. Constant change is the norm. DevOps has wide-ranging operational responsibilities.
4. Addressing DevOps security challenges AUTOMATE SECURITY EMPOWER ENGINEERING TEAMS MAINTAIN CONTINUOUS ASSURANCE SET UP OPERATIONAL HYGIENE
5. DEMO
6. References • https://github.com/azsk/DevOpsKit-docs

Notas do Editor

Engineering teams have increased autonomy. In the past, engineering teams waited weeks or months for development resources. Now that IT no longer provisions development environments, we don’t have a significant impact on scheduling or capital expense. With DevOps in the cloud, autonomy and decentralization allows engineering teams to work end to end with almost complete independence from IT. Engineering teams can instantly provision test environments, and solutions can be deployed and published with an Azure subscription at whatever pace suits the team and business stakeholders. Traditional security methods hinder this agility.
• More development technologies are available. Developing in the cloud opens up a huge opportunity for connecting different platforms and frameworks, but as flexibility has increased, so has the number of APIs and services used to make those connections. The cloud app development environment is more complex, and maintaining security in that environment using traditional methods is also more complex—and sometimes isn’t possible.
• Constant change is the norm. With the shift to agile sprints and DevOps, constant change is the norm. The platform components on which applications run keeps changing, improving, and growing—often at a cadence dictated by individual Azure service teams. On top of that, dedicated business unit application teams regularly add new functionality and improve existing functionality following the agile philosophy of incremental but continuous improvement. Traditional security and the associated tollgate procedures aren’t designed for such continuous change.
• DevOps has wide-ranging operational responsibilities. In the DevOps era, there isn’t a hard boundary between development and operations. The engineer who developed a feature is also responsible for the operational aspects of the feature. Operational considerations, including security, are a high priority for the development team in a DevOps culture.
Faced with these DevOps security challenges, we set out to determine how security could be managed in a DevOps ecosystem. We wanted to change our thinking, methods, and tools to adapt to a development environment and culture that was in harmony with the nuances inherent in cloud DevOps. To do this, we adopted a number of imperatives.

Automate security
Automation gives us a chance to keep pace with the constantly changing cloud environment. DevOps is heavily centered on end-to-end automation, and we need to complement it with automated security. Automated security saves significant time and cost for apps that update much more often than their traditional counterparts, and it allows us to ensure that security configuration and deployment in DevOps can be achieved quickly and consistently.

Empower engineering teams
In an environment where change is constant, we want to empower our engineering teams to make meaningful, consistent changes without a tedious approval process. Our engineers need to be able to build security into their applications from the start. We need security integrated into the DevOps workflow. Developers don’t have to take extra measures to be secure, nor do they need to wait for a central security team to approve an app.

Maintain continuous assurance
When development and deployment are continuous, everything that goes with them needs to follow suit, including security assurance. The age-old requirements for sign-offs or compliance checks create tension in the modern engineering environment. We want to define a security state and track drift from that state to maintain a consistent level of security assurance across the entire environment. This helps ensure that builds and deployments that are secure at the time they are delivered, stay secure from one release iteration to the next and beyond.

Set up operational hygiene
We need to have a clear view of our DevOps environment to ensure that operational hygiene is in place. In addition to understanding operational risks in the cloud, DevOps operational hygiene in the cloud requires a different perspective than the traditional development environment. We need to create the ability to see the security state across DevOps stages and establish capabilities to receive security alerts and reminders for important periodic activities.
What do you want to use the secure devops kit for?
As you can see from the summary description above, the "Secure DevOps Kit for Azure" (we will call it AzSK to be brief hereafter), can be used by many different stakeholders. So depending on your role in the DevOps ecosystem, one or more of the below scenarios may apply to you. The skillset needed to use the capabilities of the kit and the prerequisites you need to have on your machine will vary based on your scenario. Here are a few sample stakeholders and some points about how they may try to use the AzSK:
A secure cloud subscription provides a core foundation upon which subsequent development and deployment activities can be conducted. An engineering team should have the capabilities to deploy and configure security in the subscription including elements such as alerts, ARM policies, RBAC, Security Center policies, JEA, Resource Locks, etc. Likewise, it should be possible to check that all settings are in conformance to a secure baseline.
During the coding and early development stages, developers should have the ability to write secure code and to test the secure configuration of their cloud applications. Just like build verification tests (BVTs), we introduce the concept of security verification tests (SVTs) which can check for security of various resource types in Azure.
Test automation is a core tenet of devops. We emphasize this by providing the ability to run SVTs as part of the VSTS CICD pipeline. These SVTs can be used to ensure that the target subscription used to deploy a cloud application and the Azure resources the application is built upon are all setup in a secure manner.
In the constantly changing dev ops environment, it is important to move away from the mindset of security being a milestone. We have to treat security as a continuously varying state of a system. This is made possible through capabilities that enable continuous assurance using a combination of automation runbooks, schedules, etc.
Visibility of security status is important for individual application teams and also for central enterprise teams. We provide solutions that cater to the needs of both. Moreover, the solution spans across all stages of dev ops in effect bridging the gap between the dev team and the ops team from a security standpoint through the single, integrated views it generates.
Lastly, underlying all activities in the kit is a telemetry framework that generates events capturing usage, adoption, evaluation results, etc. This allows us to make measured improvements to security targeting areas of high risk and maximum usage before others.
Fetch information about various AzSDK components
Overview
Subscription information
Control information
Attestation information
Host information
This command provides overall information about the AzSDK which includes subscription information (alert/policies/ASC/CA version etc.), security controls information (severity, description, rationale etc.), attestation information (statistics, attestation justification, expiry etc.), host information (AzSDK settings/configuration, AzureRM Context etc.). ‘Get-AzSDKInfo’ command can be used with ‘InfoType’ parameter to fetch information.

DevSecOps

Esté a ler uma amostra.

Confira estes a seguir

DevSecOps

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Mais de Cheah Eng Soon (20)

Mais recentes (20)

DevSecOps

Notas do Editor

DevSecOps

Esté a ler uma amostra.

DevSecOps

Recomendadas

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Mais de Cheah Eng Soon (20)

Mais recentes (20)

DevSecOps

Notas do Editor