One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 826776 |
| Date de publication | 2018-10-01 13:00:00 (vue: 2018-10-01 16:01:46) |
| Titre | Observability and Visibility in DevSecOps |
| Texte |
To celebrate AllDayDevOps coming up October 17 - here's an on-topic blog.
Automation is Your Friend DevSecOps
Companies often turn to software as a solution when they need to solve a problem. Whether it’s to automate or enhance a task, or gain valuable information in an easily consumable fashion. The same is true for security teams on both sides of the red and blue line. Security professionals build tools to automate exploitation, detect attacks, or process large amounts of data into a usable form. By allowing staff members to understand how these software solutions behave in live environments, security teams can avoid common pitfalls. They can also increase the value that they receive from these tools overall.
When discussing software design, the word “visibility” gets tossed around a lot. People may use the word to describe the benefits provided by the software. They may use it to describe a quality of the software’s operation. They may even use it to describe how easy it is to gain an understanding of how the software was designed (i.e. open source). This has led me to believe that when we are talking about visibility, we are really talking about three specific concepts that form this bigger idea:
Insight - the valuable data received due to the software’s function
Transparency - being able to see how software is designed to function
Observability - the ability to view the actual actions software takes and its performance while taking those actions
For consumers of software, insight is the big focus, mostly because it is perceived as relating directly to value. As the role of security teams evolve, both offensive and defensive, these teams have realized that they can't just be consumers. Security teams need to be builders, maintainers, and providers. Security processes, procedures, and software need to be consumable by the greater organization. While good insight and consumable data are a requisite for quality software; what increases buy-in, improves impact in the org, and ultimately makes security software successful are the observability and transparency aspects.
Transparency in Security
In modern agile and DevOps style software development organizations, everything is in source (other than secrets), and every service has mandatory levels of documentation. Engineering teams operate this way in order to foster inter- and intra-team operability of services, to streamline troubleshooting in the event of an outage, and to increase the understanding of how individual services interact with other environment or application components.
Breaking Down Barriers to Collaboration in DevSecOps
For security teams that solve problems by writing code, or who actively work with code written by other teams, conforming to this pattern goes a long way. The similarity in process helps break down barriers to collaboration. Removing any disparity in quality between the systems being secured and the systems doing the securing helps normalize the idea that security is just one quality of the system. Leveraging a transparent approach fosters a greater degree of understanding between the security organization and the rest of the enterprise.
This idea of transparency might cause some shudders on the red side of security: historically, notions of operational security and stealth have permeated red practitiones' methods. These notions are indeed good things when conducting adversarial simulation or incident response, but there is no reason to conceal the function or performance of security software from the teams that have to interact with it outside of these specific scenarios. It is almost a cliché now t |
| Envoyé | Oui |
| Condensat | > devsecops em; observability visibility |
| Tags | Guideline |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.