devopsy.kinsta.cloud

Category: DevSecOps

  • Optimizing Security in Data Collection Processes

    Optimizing Security in Data Collection Processes

    How you collect and process your data has a direct impact on the security of that data. By following best practices for data collection and processing, DevOps professionals can minimize the risk of data breaches and other security threats. In this article, we’ll share some best practices and tips for optimizing your data collection processes for better security.

    Make use of rotating proxies

    One way to optimize data collection processes is to make use of rotating proxies. This will help to prevent your IP address from being banned or blocked by web servers. Rotating proxies will also help to increase the anonymity of your data collection process.

    Use a Secure Connection

    When you are configuring data collection processes, it is important to ensure that all data is transmitted using a secure connection. This can be accomplished by using TLS/SSL encryption for all communication channels. This will help to protect your data from being intercepted by third parties and will also ensure that the data remains confidential.

    Implement Access Control Measures

    Another important way to secure your data is to implement access control measures. This means that you will need to restrict access to the data to only those individuals who need it. You can do this by using role-based access control or by implementing a least-privilege model. By doing this, you can help to prevent unauthorized access to the data while still giving different business functions across the organization access to the data and tools they need to do their jobs well. 

    Use Data Encryption

    Another way to protect your data is to encrypt it. This means that the data will be converted into a coded format that can only be decrypted by authorized individuals. This can help to prevent unauthorized access to the data and can also help to ensure the confidentiality of the data. There are a variety of encryption methods available to you, including public key encryption and symmetric key encryption.

    Make use of Data Loss Prevention Measures

    Another way to protect your data is to make use of data loss prevention measures. This can help to prevent accidental or unauthorized deletion or modification of the data. Data loss prevention measures can include things like setting up auditing and logging, implementing data recovery plans and using access control measures.

    Create Backup Copies

    It is also important to create backup copies of your data. This way, if the data is lost or corrupted, you will still have a copy that you can use. You should store the backup copies in a secure location and you should encrypt them to help protect the data. The reason backups are such an important part of modern cybersecurity comes down to the threat of ransomware and the rise of cyberextortion.

    Ransomware groups around the world have been increasingly targeting businesses of all sizes in recent years in an effort to extort money from them. And while some businesses have been lucky enough to avoid being targeted, others have not been so fortunate. The end result can be a total loss of reputation and even bankruptcy.

    Monitor Activity

    Another way to help secure your data is to monitor activity. This means that you will need to track who is accessing the data and what they are doing with it. This information can be used to identify unauthorized access and can also help you to determine if the data is being used appropriately.

    Restrict Physical Access

    It is also important to restrict physical access to the data. This means that you will need to ensure that only authorized individuals have access to the physical location where the data is stored. This can help to prevent unauthorized access and can also help to protect the data from being damaged or destroyed.

    Destroy Data When no Longer Needed

    When you no longer need the data, it is important to destroy it. This means that you will need to delete the data from all storage devices and ensure that it cannot be recovered. This can help to prevent unauthorized access and can also help to protect the data from being used inappropriately.

    Implement Security Policies and Procedures

    It is also important to implement security policies and procedures. This means that you will need to develop policies and procedures that govern how the data is to be used and accessed. These policies and procedures should be reviewed regularly and updated as needed.

    Educate Employees

    Another way to help secure your data is to educate employees. This means that you will need to provide training on the importance of protecting the data and on the procedures that should be followed. This training can help to ensure that employees are aware of the importance of security and can also help to prevent unauthorized access.

    Employee education is your first line of defence against cybercrime because your people constitute your largest threat and cybersecurity vulnerability. This is not because of maliciousness or nefariousness, but simply because most people are not aware of many of the necessary cybersecurity best practices when it comes to data collection and handling.

    Conduct regular audits

    It is also important to conduct regular audits of the data. This means that you will need to review the data regularly to ensure that it is being used appropriately and that no unauthorized access has occurred. This can help to identify any security issues and can also help to ensure that the data is being used correctly.

    Use encryption

    As mentioned before, another way to help secure your data is to encrypt it. This means that the data will be converted into a coded format that can only be decrypted by authorized individuals. This can help to prevent unauthorized access to the data and can also help to ensure the confidentiality of the data.

    Implement access control measures

    Another way to help secure your data is to implement access control measures. This means that you will need to restrict access to the data to only those individuals who need it. This can help to prevent unauthorized access and can also help to ensure that the data is being used appropriately.

    Conclusion

    When it comes to data security, there are a number of steps that you can take to help protect your information. By taking the time to implement these measures, you can help to ensure that your data is safe and secure.

  • Shift Left is Only Part of Secure Software Delivery

    Shift Left is Only Part of Secure Software Delivery

    We’re living in the age of accelerated consumption and delivery. You can get a seemingly infinite selection of products delivered to your door within two days, for free, from thousands of miles away. You can access an endless variety of services online within mere seconds: Movies, music, games, education and even health care. These modern marvels are afforded to us by relatively recent advances in software development, delivery and operations. 

    Among those advances are the adoption of DevOps practices, continuous integration and continuous deployment (CI/CD) pipelines, and automating everything from infrastructure provisioning to testing and quality assurance. These advances enable developers to deliver software faster and think about security earlier in design and development to ship safer software.

    What is Shift Left” and Why Does it Matter?

    “Shift left” is a philosophy for addressing the pitfalls of traditional waterfall-style development. In waterfall, a number of IT teams work over the course of many weeks or months, culminating in a big and beautiful software release. Of course, people make mistakes, forget things, and maybe don’t communicate well with each other. When it turns out that application elements don’t interoperate well, the teams frantically attempt to fix what’s possible and jettison what isn’t, with a very serious deadline staring them in the face. Products inevitably ship late, still somewhat broken, and with security bolted on as an afterthought.

    To shift left means to introduce security process and tooling earlier into the design and development phases. Security should be just as critical as functionality and quality. It’s a great idea because discovering a critical, build-failing vulnerability in a critical dependency after you’ve built dozens of functionalities on top of it hurts a lot more than if it’s found before you build anything at all. Maybe fixing the problem is as simple as using a newer version of a dependency, but now you have to make sure everything you’ve customized still works as intended.

    There are a number of forms of application security testing (AST) that aim to detect code-level issues early in the systems development life cycle (SDLC). Two common types of AST when shifting left are software composition analysis (SCA) and static application security testing (SAST). Put simply: SAST tests the custom code your developers write; SCA tests dependencies you include in code. 

    Assessing the security of modern applications requires both testing types. If you believe shift left means not only finding problems but also fixing them, then developer-friendly tooling is necessary. Exactly what that means can be subjective depending on developer workflows in the organization, but at the very least, developers need self-service, seamless integration into their existing CI/CD toolchains and actionable results. Because most developers aren’t security experts, security findings must prioritize the riskiest problems, point to the source of the issue and provide contextualized fixes, rather than making the developer hunt for them on their own. 

    Augmenting AST With Runtime Intelligence

    One challenge with doing a lot of early testing—especially security testing—is that the more you test, the more findings you discover. Unfortunately, some of the results will be false positives and others may be true positives that pose a relatively low risk. Development teams with a high degree of security expertise must sift through and vet findings to prioritize flaws that are severe and actionable, but such practitioners are in short supply and this type of work is tedious.

    Addressing the pitfalls of security testing isn’t simple, and it involves gathering as much contextual information as possible to begin to reason about the risk associated with each finding, usually expressed by what exploitable code is actually exercised. 

    Reasoning about vulnerability risk is not easy. We try to rank the criticality of issues to decide on an action. We can split the problem into two parts: 

    • The context of the vulnerability itself includes metrics of severity, like the CVSS score, and threat intelligence, like whether exploits are publicly available or attacks are prevalent in the wild. This information is readily available from scanning tools and third-party sources like NVD, MITRE and CISA.
    • The afflicted asset’s environmental context, however, is specific to your application and your infrastructure. Only your organization can really fill this part in. For example, is the impacted application protected by mitigating security controls? Is it exposed to the internet? Does the vulnerable component even get used at all? This is difficult or impossible to know until the application is running in its intended production environment. 

    Shift left is a way forward for modern cybersecurity, but the approach can be vastly enriched by pulling in runtime intelligence. This helps to prioritize what to fix first, removes friction, saves cycles of numerous IT teams and reduces your organization’s vulnerability risk.

    What Happens After Release?

    The whole point of shift left is to release secure software faster, but what happens next? Your flawless, beautiful code is delighting your customers with its stunning feature set and impressive performance. Then, on some idle Friday afternoon, right before what should have been a long holiday weekend, you get hit with a horrendous zero-day that you could never have predicted even if you tried. 

    When that happens, you need to respond by quickly identifying all of the affected workloads running in your environment and prioritizing them for remediation. You may need to take those workloads offline to patch immediately, limit network access to them, or otherwise mitigate the problem if a patch is either unavailable or taking too long to deploy. The point is that in real life, shift left is only one part of a successful security program, and the protective, detective, and remediation activities for your production environments on the right are also critically important to your organization’s safety and success.

    Conclusion

    Shift left alone was never going to solve all security problems, but it does create foundations for reliable, fast and secure software delivery pipelines. Security and development teams alike often suffer from a deluge of noise and few useful signals. What they really need are consistent and prescriptive ways to make sound decisions about risk. Gathering context from multiple sources through multiple layers of the stack, including runtime signals, substantially improves the quality of the information that DevSecOps teams receive from their tools and must act on.

    Effi Goldstein, director of products at Snyk, co-authored this article. Check out Sysdig and Snyk’s 2022 Container Security Trends: Expert Panel Livestream for more information. 

  • Blast Radius of GitHub Breach Major Security Concern

    Blast Radius of GitHub Breach Major Security Concern

    The extent to which software supply chains may be compromised in the wake of a security breach disclosed by GitHub may include thousands of organizations.

    GitHub has revealed that unauthorized parties compromised OAuth user tokens maintained by Heroku, an arm of Salesforce that provides a platform-as-a-service (PaaS) environment, and Travis CI, a provider of a continuous integration/continuous delivery (CI/CD) platform. GitHub has since disconnected the third-party applications that were employing those tokens to access repositories but how much any code might have been exfiltrated or, worse yet, modified may not be known for weeks.

    “There’s a lot of directions this could take,” said Mitch Ashley, principal researcher for Techstrong Research, an arm of Techstrong Group, which owns devopsy.kinsta.cloud. “This is an attack against an authentication mechanism.”

    In fact, the full extent of the blast radius of the breach may never be known unless every organization employing Heroku or Travis CI platforms discloses whether their software supply chains were breached. GitHub has also yet to provide any timeline for the extent of the breach, so no one affected yet knows how far-reaching an investigation should be launched or how long it could take to discover malicious code that may have been injected into applications, noted Brian Soby, CTO at AppOmni, a provider of a platform that provides visibility into platform configurations.

    “We don’t know yet when this occurred,” he said. “This could have a big blast radius.”

    In the meantime, the GitHub disclosure will only intensify security reviews of software supply chains, which have begun in earnest in the wake of a series of high-profile breaches that started with an incident involving an IT service management platform provided by SolarWinds.

    In the case of the latest GitHub breach, security professionals are surmising that developers hard-coded tokens into applications accessing GitHub to make it easier to access repositories. “Developers are lazy,” said Demi Ben-Ari, CTO for Panorays, a provider of a platform for evaluating third-party security risks. “They like to take shortcuts.”

    Some organizations in the wake of the attack may move to distribute source code across repositories from multiple vendors as part of any effort to better secure their intellectual property, noted Ben-Ari.

    Organizations also may decide to rely on code repositories that are not accessed via the cloud. However, given the need to integrate disparate services across a software supply chain, there is no guarantee that an organization with a repository running in an on-premises IT environment wouldn’t be affected by a similar attack.

    On the plus side, as more organizations become aware of the threat vector employed to compromise the GitHub repositories, the level of awareness for implementing best DevSecOps practices should increase. The challenge, of course, remains bridging the technical and cultural divides that often result in developers not following best security practices when building and deploying applications. However, as the number of incidents continues to mount, more organizations are beginning to appreciate just how easy it is for the code they are relying on to engage customers and suppliers to be tampered with or outright stolen.

  • How Engineers Can Contribute to API Security

    How Engineers Can Contribute to API Security

    I’m an engineer, not a security professional. I’ve worked at several startups over the years and have discovered ways to shift my engineering mindset to include a security focus and to incorporate security into my coding practice. 

    I’ve found that when you work with others, an engineering organization can significantly contribute to API security. But how we think about software makes it difficult to get started. There is an alternative perspective—a road not taken—that must be considered when it comes to securing endpoints from threat actors. 

    The Road Not Taken

    Engineers create and optimize applications to solve problems for real users. Engineering time is often in short supply, so we optimize the speed at which we can write those applications. To speed up our processes, we simplify problems and find reusable patterns or techniques. Add a bit of glue, and you have software.

    This perspective is constructive. Thoughts come first and software comes next. And when refactoring existing code for software, we need to think this way. But this utility comes at a cost: If the software works, we only see what it should do. The real story behind the scenes can be much more complex.

    A few years ago, I worked with an engineer on new endpoints for an authorization API. We were working out an issue in the implementation where I could call the endpoints out of order and bypass a challenge. We worked through the example, and he said, “But they are supposed to be called in 1-2-3 order.”

    Attackers don’t share this perspective. Instead, they want to manipulate the software to act in their own interests. They ask, “What is possible?” instead of “What is it supposed to do?” and find ways in which the system fails. To an attacker, the glue is more interesting than the design.

    While probing, an attacker may be thinking some of the following questions: 

    “The password reset endpoint is on v2? Is v1 still running?” 

    “What happens if I skip the verify endpoint?” 

    “What happens when I pass null in the challenge? Empty string? SQL injection?”

    As creators, we’ve converged on this constructive perspective. To build secure software, we need to consider the road not taken and incorporate greater security into our applications.

    Playing Defense

    When you are defending software, your limited time is a disadvantage. There are many engineers—and some have been writing software for many years—which means that you have a lot of code to defend. Each application depends on hundreds or thousands of open source projects, from libraries to deployment tools to server operating systems. 

    Security tools can help you think from both perspectives, especially those that automatically discover endpoints and track response statistics. You can use this data to understand how code maps to your public API surface. 

    In addition to tools, here are several suggestions for on the ground techniques that you could try out.

    Read the Code

    Pick an application, find out where the authentication and authorization code is and read it. Even if you aren’t a strong coder, you can learn something interesting. Better yet, try and take the attacker’s perspective and look for ways you can exploit the code and make it work for you. For instance, you may see the following:

    “SQL injection might be possible in this area. I might be able to extract information about other accounts.”

    “Authorization is complex and confusing in this area. I might be able to use my standard user account to execute actions on other accounts.”

    “Logging is very weak in this sensitive area. I might be able to hammer this endpoint without being noticed.”

    “Code or comments indicate the developer assumes the application is secure for a particular reason. Can I break those assumptions with an external request?”

    The knowledge gained in performing an exercise like this is priceless. You can use it to guide the rest of your API/AppSec work (pentesting, scan remediation, etc.). Further, you’ll often find logical vulnerabilities that scans couldn’t detect.

    Read Code Reviews

    Engineers make decisions in pull requests (PRs). Content in past PRs and review comments have tons of context and can be used to help inform your decision-making. Look through the history, then think through some security-focused review questions:

    “If the code tries to enforce security constraints, can I think of a way around them?”

    “Are there obvious security mechanisms that should be part of this change but are missing?”

    “Would unusual attacker behavior appear in logs?”

    Examining these reviews and understanding the broader context can provide you with valuable information. You might find a sensitive action without any authorization logic, ways a user account can access data owned by other users, or a path through the password reset flow without a valid challenge token.

    Work With Engineers

    If your engineers are working on security-relevant code, ask for some time to talk. Find out what they are working on (and why). Help them think like an attacker, and explain some of the techniques an attacker might use to break their app. And remember to take the road not taken while you work to ensure the security of your applications. 

  • ForAllSecure Adds Free Testing Tools for OSS

    ForAllSecure Adds Free Testing Tools for OSS

    ForAllSecure is investing to make open source software (OSS) more secure and is making available free, personal-use versions of its Mayhem application security testing tools infused with artificial intelligence (AI) capabilities to anyone using GitHub repositories.

    Company CEO David Brumley said anyone who integrates Mayhem into a qualified GitHub repository being used to build open source software will receive $1,000 as part of the company’s Mayhem Heroes program.

    There are now two free, personal-use editions of Mayhem that can be used to analyze code or application programming interfaces (APIs). Those tools are based on fuzz testing technology, which randomly injects data into applications to detect vulnerabilities as part of an effort to automate DevSecOps processes.

    In the wake of the discovery of zero-day vulnerabilities in open source software that have impacted enterprise IT organizations, more attention is being paid to how open source software is created, maintained and secured. Many of the developers who build and maintain open source software don’t typically have a lot of cybersecurity expertise, and don’t have the time and resources required to continually remediate vulnerabilities as they are discovered. The Mayhem application security testing tools are designed to make it faster to discover vulnerabilities using AI technologies to reduce the number of false-positive alerts.

    It’s too early to say how quickly open source software might be made more secure, but tons of resources are being made available. The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, has raised more than $10 million to build tools and define best practices for securing open source software projects. Google has pledged to spend $10 billion to improve open source security. The Biden administration has also made improving the security of open source software used inside (and outside) government agencies by expanding compliance mandates. The White House is also trying to encourage IT vendors and larger enterprises to contribute more to the effort to secure open source software.

    The pressure is rising on both developers and consumers of open source software to make sure open source software is secure. However, many open source projects are maintained by a small number of programmers who contribute their time and effort to build components that others are free to use. Many of them argue it is the responsibility of the organizations that deploy that software to ensure the software is secure  Many IT vendors and large enterprise IT organizations that rely on that code aren’t contributing anything meaningful back to the project, in terms of either financing or just helping open source maintainers find and remediate vulnerabilities. The irony is many of those same organizations are now assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions.

  • How DevSecOps Teams Can Level Up

    How DevSecOps Teams Can Level Up

    In 2019, I wrote a post detailing the traits of DevSecOps—the practice can be defined as the process of security automation in which IT and security are more de-siloed. DevSecOps introduces a more intentional culture wherein security-by-design principles are baked into the software development process early on. All in all, the aim is to have security enable development, not stall IT and slow down the SDLC.

    So, years later, how is DevSecOps doing? Has it achieved this ideal? Well, I recently met with Jeff Williams, CTO and co-founder of Contrast Security, for insights into the state of modern DevSecOps. According to Williams, most large companies still have real problems with application security and software dependency providence is constantly in question. We’ve recently seen this reality rear its ugly head amid exploits in frameworks like Log4j and Spring4Shell.

    Large organizations are likely carrying tens of thousands of vulnerabilities in their backlog. Yet, as consumers, we happily trust software for our critical applications without knowing what lurks behind it. “The industry has a real transparency problem,” said Williams. And as applications are getting more interconnected, they are getting more complicated and they’re getting more critical, Williams added. “These three Cs—connected, complicated and critical—make security harder.” These conditions are culminating in what he called “a perfect storm.”

    6 Ways DevSecOps Teams Should Respond

    So, how should DevSecOps teams respond to the seemingly endless barrage of new vulnerabilities and attacks? Williams shared some general ways teams can increase their security posture.

    1. Practice Security in Sunshine

    It’s easy to point fingers when something goes wrong, especially if it’s a serious vulnerability or attack. Instead, Williams encouraged teams to practice what he calls “security in sunshine.” This is an attitude that gives more transparency to security issues internally. Embracing a culture of blameless retrospectives can ensure employees are comfortable bringing up issues within their team.

    Security in sunshine can be adopted in an external-facing way as well. Williams likened it to how, in product manufacturing, it’s standard practice to share a bill of materials (BOM) with trade partners. We may see similar labeling standards emerge for software in the form of software bills of materials (SBOMs) so that external consumers are better aware of dependencies and potential threats, Williams suggested.

    Cybersecurity awareness certainly takes a communal effort that requires transparent communication. We see this realized daily in bug bounty programs, CVE reports and fixes to open source software. Bringing potential threats into the light of day is necessary to squash vulnerabilities before they are exploited.

    2. Translate High-level Requirements

    Security guidelines issued by bodies such as NIST and ISO are essential to keep in mind. Implementing the concepts these guidelines recommend, such as the principle of least privilege, multifactor authentication and zero-trust architecture, are considered best practices by most security professionals. However, these high-level requirements don’t often translate down to the developer on the ground floor. “The developer needs those requirements translated down four levels to specific technologies they’re working with,” said Williams.

    A programmer needs more realistic advice on how these guidelines affect, say, Spring Boot applications or how they should configure permissions in AWS. According to Williams, teams must interpret these abstract recommendations with more concrete annotations that meet the nuances of the technology stack they’re working in. The same process is required to help developers create projects compliant with data regulations, as it’s difficult to take this high-level advice into practice. Translating these requirements into more readable terms is an excellent way to de-silo security and development teams.

    3. Shift Smart

    In recent years, there’s been a lot of talk about shift left. The idea is that to reduce security threats later on, organizations need a tighter grasp on security earlier in the software development life cycle. Shifting security left is often enabled with tools that hold code accountable for potential threats using automated analysis.

    However, Williams sees this as an area where organizations need to be careful. Not all security tools are developer-friendly and might introduce inefficiencies at scale. Instead of shifting left, he advocates for “shifting smart” to introduce security at junctures where it’s most efficient. “You don’t want to shift all security left—you want to shift right too,” explained Williams. “Spread it out over the whole life cycle.”

    4. Avoid Added Steps

    There’s more than one way to bake a cake. Similarly, there’s more than one way to cook up a great software application. As such, most organizations are dealing with multiple tools, making it harder to apply security consistently across all stacks.

    Security should be catered to the specific tooling and processes being used, Williams explained. But that requires answer certain questions like where is a software development team in their journey? Are they waterfall or Agile? How does each CI/CD pipeline behave?

    Obviously, there are many unique factors to consider. Ideally, tooling should be flexible enough to attach itself to existing infrastructure, Williams said, instead of adding additional steps to an already sprawling tooling ecosystem.

    5. Take Security Seriously

    And, of course, there’s the cultural element. “It’s 2022, and companies still don’t take security seriously—they need to change,” said Williams. “It doesn’t matter how they get there—that they get there matters most.”

    Admittedly, cultural change is a slow evolution and the best way to advance will be to add practices and technologies progressively over time. Thus, Williams recommended iteratively inserting pieces, measuring outcomes and proving value along each step of the journey.

    6. Update Outdated Tools

    WhiteHat Security found the average time it took to fix critical vulnerabilities in the spring of 2021 was 205 days. But such a long timeline is at odds with the pace of new threats and the need to patch them quickly.

    The industry is changing the way they do AppSec, said Williams. Traditional DevSecOps security tools, he said, such as static analysis tools, dynamic analysis tools and web application firewalls, are outdated and less accurate compared to newer technologies like interactive application security testing (IAST) and runtime application self protection (RASP). Accuracy, speed and scalability will be important characteristics for security automation tools that don’t require additional human intervention or produce too many false positives.

    DevSecOps Is Still Maturing

    A healthier DevSecOps practice aims to decrease the “vulnerability escape rate,” as Williams called it. Hopefully, by providing instant feedback on designs, engineers will learn not to repeat the same mistakes, thus decreasing the number of vulnerabilities they introduce.

    In summary, DevSecOps is still maturing. Looking to the future, a stronger DevSecOps approach will require a more open attitude to mitigate threats. It also requires practical guidance as not all top-down guidelines translate well into the active development environment. Applications will require proper code hygiene, and the software supply chain itself must be protected, too, in addition to conducting active monitoring of production environments.

  • The Rising Demand for DevSecOps Talent

    The Rising Demand for DevSecOps Talent

    Demand for DevSecOps talent and skills is growing even faster than the demand for DevOps.

    The global DevSecOps market is anticipated to register a CAGR of 32.2% over the next few years, and revenue is projected to grow from USD $2.55 billion in 2020 to USD $23.42 billion in 2028. No wonder the number of job postings for DevSecOps is rising.

    Many organizations are implementing DevSecOps in their workflows. Some famous names include Netflix, Etsy, Twitter, Facebook and Google. Those who are already well-versed in DevOps and who have a security background will have an advantage over others in this field when looking to get hired.

    However, it is not just about the tools and technologies—there is a lot more to DevSecOps than that. It is also about culture and new ways of working; about automating the security process and making security a part of the continuous delivery pipeline.

    What is DevSecOps? What’s inspiring top business leaders to invest in this domain? And how will acquiring these skills help you in your career?

    What is DevSecOps?

    DevSecOps is a set of practices that combines the speed and agility of DevOps with security controls. It aims to help organizations deliver software faster while ensuring that the applications are secure. The term ‘DevSecOps’ was first coined by John Willis and Damon Edwards in 2009. They defined it as:

    “DevSecOps is the practice of operations and development engineers participating together in the entire service life cycle, from design through the development process to production support.”

    Later, Gartner offered the following definition of DevSecOps:

    “DevSecOps is the dynamic software development approach that incorporates security as a critical element of the application delivery process from design to production.”

    In simple terms, DevSecOps can be defined as a culture and set of processes that help organizations to deliver secure software faster. As the demand for DevSecOps professionals rises, it is an excellent time for software engineers, developers and DevOps professionals to consider a career in this domain. Here are some of the top reasons why you should consider a career in DevSecOps:

    1. It is a rapidly growing field

    The DevSecOps market is anticipated to grow at a CAGR of 32.2% between 2020 and 2028. This rapid growth is creating a lot of job opportunities for DevSecOps professionals.

    2. It is an interdisciplinary field

    DevSecOps is not just about the tools and technologies. It is an interdisciplinary field that requires skills in development, operations, and security.

    3. High-paying roles

    According to a recent survey, the average salary of a DevSecOps professional is $123,000 per year or higher; much higher than the average salary in other fields.

    4. Work with the latest technologies

    DevSecOps is all about automating the software delivery process. It requires a deep understanding of the latest DevOps tools and technologies as well as automation, AI and machine learning.

    5. Stay ahead of the latest trends

    As a DevSecOps professional, you need to be on the cutting edge of the latest trends in the industry. A role such as this helps you keep your skills up-to-date and stay ahead of the curve.

    Why the Major Investment?

    The following factors are inspiring top business leaders to invest in DevSecOps:

    1. The need for speed

    In today’s fast-paced world, businesses have to deliver software faster. DevSecOps helps organizations speed up the software delivery process while ensuring that the applications are secure.

    2. The need for agility

    DevSecOps enables organizations to be more agile and adapt to ever-changing market trends. The ability to quickly deliver software helps organizations stay ahead of their competition and do so while reducing the risk of data breaches, cyberattacks and malware.

    3. The need for security

    As cyberattacks continue to rise, businesses are investing in DevSecOps to ensure that their applications are secure. DevSecOps helps organizations detect and fix security vulnerabilities earlier in the software development process when they are easier and less costly to fix.

    In 2021, there were around 414,02,809 cybersecurity incidents worldwide and that number will likely increase. With the help of DevSecOps, businesses can protect their applications from attacks.

    4. The need for compliance

    With the help of DevSecOps, businesses can automate the compliance process. It helps save time and resources otherwise spent on manual compliance processes.

    5. The need for cost savings

    DevSecOps helps organizations save money by automating the software delivery process. Automation helps reduce the need for manual labor, which can help cut costs.

    Professional Skills and Requirements

    Like any other field, DevSecOps also has its own set of requirements and skills you need to know to be successful. While many are specific to technology and tools, others are more general soft skills.

    1. The need for cross-functional skills

    Since DevSecOps is an interdisciplinary field, professionals in this role need to understand both development and operations. They also have to be familiar with the latest tools and technologies in software development, IT operations, security, CI/CD, containers and more.

    2. The need for collaboration

    DevSecOps is all about collaboration between different areas of the business and different teams. Professionals need to be able to work closely with other team members.

    3. The need for continuous learning

    As the DevOps and security fields are constantly changing, professionals need to constantly update their skills and be familiar with the latest trends in the industry.

    4. The need for patience

    The software delivery process is often slow and complex. It can be frustrating for professionals who are used to working in a fast-paced environment.

    5. The need for adaptability

    As the DevOps and security fields are constantly changing, professionals need to be adaptable. They should be able to learn new tools and technologies quickly and know how to apply that knowledge to solving technology problems.

    Getting Started

    If you want to become a DevSecOps professional, you need to understand both software development and operations. You also should be familiar with the latest tools and technologies. You can read other professionals’ blogs, take formal courses or attend a coding bootcamp, take courses at a community college or university or teach yourself. You should attend conferences and talk with other technology professionals to share knowledge. In addition, you need to work on your soft skills, including communication, collaboration, teamwork and leadership.

  • 15 DevSecOps Best Practices

    15 DevSecOps Best Practices

    DevOps is all about speed, agility and collaboration. But when it comes to security, DevOps teams often face unique challenges. From securing the application development process to protecting production environments, DevOps and DevSecOps teams need to be aware of a variety of potential security risks.

    To help you stay ahead of the curve, we’ve compiled a list of 15 DevOps security best practices and challenges.

    1. Secure your application development process

    The first step to securing your DevOps pipeline is to ensure that your application development process is secure. This means ensuring that only authorized developers have access to your code repositories and that all code changes are reviewed and approved by a qualified reviewer before being merged into the main branch. It also helps to have developers that you trust to do the job properly and to observe cybersecurity best practices throughout. Consulting places like rightpeoplegroup.com makes finding these kinds of professionals much more straightforward. 

    2. Protect your production environment

    Your production environment is where your application will ultimately be deployed and used by your customers. As such, it’s important to ensure that this environment is as secure as possible.

    One way to do this is to segment your production environment into separate tiers, each with its own level of access and security controls. This way, even if one tier is compromised, the others will remain protected.

    3. Implement least-privilege principles

    In general, it’s best to follow the principle of least privilege when it comes to granting access to your DevOps resources. This means giving users only the permissions they need to perform their job and no more. The reason this is so important to follow is that your employees constitute your biggest cybersecurity threat. This is not always for nefarious reasons, but often simply because they do not have the knowledge or understanding to keep your business digitally secure at all times.

    4. Use role-based access control (RBAC)

    Role-based access control (RBAC) is a type of access control that can be used to restrict access to DevOps resources based on the roles of users. For example, you could create a ‘developer’ role that has access to your code repositories and a ‘tester’ role that has access to your staging environment. By using RBAC, you can help limit the damage that can be caused by an insider threat.

    5. Encrypt sensitive data

    Any data that could potentially be used to identify or harm an individual should be encrypted, both at rest and in transit. This includes data such as social security numbers, credit card numbers and health information.

    One way to encrypt data is to use pretty good privacy (PGP) encryption. PGP uses a combination of public key and symmetric key cryptography to protect your data.

    6. Use two-factor authentication

    Two-factor authentication (2FA) is an additional layer of security that can be used to protect access to DevOps resources. With 2FA, a user is required to provide two pieces of evidence to verify their identity. The first piece is something they know, such as a password, and the second piece is something they have, such as a mobile phone.

    Implementing 2FA can help to prevent unauthorized access to resources and systems, even if a user’s password is compromised.

    7. Use secrets management tools

    A secret is any piece of sensitive information that should be kept confidential, such as a password or an API key. Secrets management is the process of securely storing and managing secrets.

    There are a number of secrets management tools available, such as Hashicorp’s Vault and AWS Secrets Manager. These tools can help you to centrally manage secrets and provide access control and auditing capabilities.

    8. Train your employees in security awareness

    One of the best ways to improve DevOps security is to train your employees in security awareness. This can help them to understand the importance of security and to identify and mitigate risks.

    There are a number of different security awareness training programs available, such as the SANS Security Awareness Program. Alternatively, you could create your own program tailored to the specific needs of your organization.

    9. Use a web application firewall (WAF)

    A web application firewall (WAF) is a type of firewall that can be used to protect web applications from attack. WAFs work by inspecting incoming traffic and blocking requests that contain malicious payloads.

    There are a number of different WAFs available, both open source and commercial. Some examples of WAFs include mod_security for Apache, NGINX Plus and F5’s BIG-IP ASM.

    10. Perform regular security audits

    Regular security audits are an important part of DevOps security. They can help you to identify weaknesses in your system and ensure that your security controls are effective.

    There are a number of different types of security audits, such as penetration testing and code reviews. It’s important to choose the right type of audit for your needs. If you are unsure, you can consult with a security expert.

    11. Use intrusion detection and prevention systems (IDPS)

    Intrusion detection and prevention systems (IDPS) are designed to detect and block malicious activity. IDPSes can be used to protect both physical and virtual resources.

    There are a number of different IDPSes available, both open source and commercial. Some examples of IDPSes include Snort, Suricata and Bro. They are often deployed as part of a security information and event management (SIEM) system.

    12. Implement a disaster recovery plan

    A disaster recovery plan (DRP) is a document that outlines the steps that should be taken in the event of a disaster, a breach or other security incident. The DRP should contain information such as contact details for key personnel and procedures for restoring systems.

    A DRP can help to minimize the impact of a disaster and ensure that your organization is able to recover in a timely manner.

    13. Use logging and monitoring tools

    Logging and monitoring tools can be used to collect data about the activity on your system. This data can be used to detect and investigate security incidents.

    There are a number of different logging and monitoring tools available, both open source and commercial. Some examples of logging and monitoring tools include Splunk, ELK Stack and Nagios.

    14. Conduct regular penetration tests

    Penetration testing (or pentesting) is a type of security test that simulates an attack on your system. The goal of pentesting is to identify vulnerabilities that could be exploited by an attacker.

    Penetration tests can be conducted internally or externally. External penetration tests are often performed by third-party security firms. Internal penetration tests can be conducted by your own staff or by using a tool such as Metasploit.

    15. Use access control lists

    Access control lists (ACLs) are a type of security measure that can be used to restrict access to DevOps resources. ACLs work by defining a set of rules that determine who is allowed to access what.

    ACLs can be used to implement a least-privilege policy and can help to prevent unauthorized access to sensitive data.

    Conclusion

    There are plenty of threats when it comes to DevOps and DevSecOps and, equally, a wide range of best practices that can be used to improve DevSecOps. By implementing these best practices, you can help to protect your system from attack.

  • DevSecOps Tools: Hot Air Ahead

    DevSecOps Tools: Hot Air Ahead

    I, like most of you, don’t like hardcore marketing that hinges its statements on “Well, that’s technically true…” I also am not a fan of talking heads that spew predictions about the future. Sure, they’re right sometimes; that’s because we have so many people pontificating that random distribution means some will be correct. I am bringing all this up to warn you that I (basically a high-tech talking head) am about to talk about tools, the future of tools markets (one in particular) and what I think should/will happen.

    Sometimes, talking about the future of a given tech is done to make a name for yourself. I don’t play that game. My goal is simply to say, ‘This is what I would like to see, and why I would like to see it.’

    Enough spewing—let’s talk about DevSecOps tools. I jotted down this topic a while back when I touched briefly on it, and my ideas firmed up while working on a recent project.

    Let’s start easy. If you are not using what we currently call DevSecOps tools in your DevOps toolchain, go get them set up. Go ahead, we’ll wait. It’s that much of a no-brainer that we’ll sit here while you choose, purchase and install your choice. Seriously. “Here is a tool that will make development more secure and make developers more productive.” Go install it now. Choose what functions you want to use and work them into your toolchain.

    But don’t get too married to your vendor. Because for the very same reasons I just told you to go install them, I will say I don’t think they should be a standalone market. Here is a toolset that plugs into the IDE on one end, and runs stand-alone, integrated with CI/CD on the other. It is DevOps in many ways. And while code scanning is inarguably a security function, the spirit of DevOps overall is “Who cares?” Using these tools shifts quite a bit of security functionality left and also warns about bad coding practices. Note I did not specifically say insecure coding practices, though those are covered. I said bad coding practices. The largest of these vendors will let you know things like, “Hey, you sent that variable to this function and then never used it. Are you sure?” or “This loop looks like it never exits. Are you sure?”

    It should be, and I predict will be, part of the DevOps process. In my dream world, the functionality would get split and some would end up in IDEs, while the rest would end up in testing tools or CI tools. But that’s not normally how markets get split up when there are established vendors. Even though you can feel the difference in the functionality (a bunch of them plug right into the IDE; the rest don’t), it won’t get split up because existing markets generally merge through acquisition. So we’ll have to see how things fall out, but I’m betting on CI/CD vendors or system-wide security vendors moving into this market. Indeed, companies with a SOC will likely find these vendors appealing because most of them also operate SOCs for the dynamic scanning part of the system.

    Still don’t have DevSecOps installed? Go now. Choose a vendor.

    Because I’m being so forceful about telling you to install one of these toolsets, I’ll state very clearly: At the time of this writing, I do not have any kind of relationship with any vendor in this space. I say this because I use the tools and strongly believe that the pain points they bring as a layer in development are very much made up for by the benefits they bring to the application.

    And keep rocking it. This will just make your systems more stable, and the merges (that I see as inevitable, but is actually only a possibility) you can worry about when they come along.

  • Survey Sees Little Progress on Securing Software Supply Chains

    Survey Sees Little Progress on Securing Software Supply Chains

    A survey of 1,750 IT security decision-makers published today found that, despite a series of high-profile cybersecurity breaches, nearly two-thirds (62%) of respondents have done nothing to secure their software supply chain. A full 64% conceded that an attack against their software development environment could not be stopped. And nearly three-fourths (71%) of respondents admitted their organization suffered a successful software supply chain-related attack that resulted in data loss or compromise of an asset, while 85% acknowledged a software bill of materials would also reduce the risk of compromise to a software supply chain.

    The survey, conducted by the market research firm Vanson Bourne on behalf of CyberArk, a provider of a privileged access management (PAM) platform, also found that 87% of respondents stored secrets in multiple places across DevOps environments, while 80% conceded developers typically have more privileges than necessary for their roles. Only 3% of respondents said their organization has a centralized secrets management platform to manage credentials used by applications.

    Organizations are also struggling to keep pace with the number of digital identities that have access to IT services. The average staff member has access to more than 30 applications and accounts, the survey found. However, 68% also reported non-humans or bots have access to sensitive data and assets, with machine identities now outnumbering human identities by a factor of 45, on average, the survey found. Less than half (48%) of respondents have any type of identity security controls in place for their business-critical applications.

    Even the threat of ransomware doesn’t seem to be having much of an impact. More than 70% of respondents said their organization has experienced, on average, two ransomware attacks in the past year.

    Brandon Traffanstedt, senior director for the global technology office at CyberArk, said it’s apparent organizations are accruing a significant amount of security debt that is not being proactively addressed. In fact, more than two-thirds of respondents (69%) said their organization has prioritized maintaining business operations over ensuring robust cybersecurity in the last 12 months. A full 99% of respondents said their organization had fast-tracked the adoption of at least one business/IT initiative over the last 12 months.

    In general, hybrid working (86%), the introduction of new digital services for customers or citizens (84%) and increased outsourcing (84%) are identified as the activities that are introducing the greatest risks. Specifically, the survey found credential access (40%) was the number one area of risk, followed by defense evasion (31%), execution (31%), initial access (29%) and privilege escalation (27%).

    Real-time monitoring and analysis to audit all privileged session activity; least privilege security/zero-trust principles on infrastructure that run business-critical applications and processes to isolate business-critical applications from internet-connected devices to restrict lateral movement are tied at 54% for the top three security initiatives organizations are planning to implement. The top three strategic zero-trust initiatives are workload security (52%), identity security (50%) and data security (45%), the survey found.

    Ultimately, the only way to address the current level of security debt organizations are incurring is by embedding functionality into DevOps workflows that automatically apply security policies and teaching developers to build more secure applications, said Traffanstedt. The former approach, however, may have a bigger impact more quickly, given the current level of cybersecurity expertise that currently exists in the developer community.