devopsy.kinsta.cloud

Tag: devsecops

  • MDR for DevSecOps: How Managed Security Can Help You Shift Left

    MDR for DevSecOps: How Managed Security Can Help You Shift Left

    What is managed detection and response (MDR)? Managed detection and response (MDR) is an outsourced service that helps organizations detect threats on endpoints, respond to them and carry out proactive threat hunting.

    MDR services typically include an endpoint detection and response (EDR) platform, which is deployed on company endpoints, and human security experts. MDR providers give their customers access to security analysts and engineers who can help with endpoint security, network security management, triage of alerts and responding to real security incidents (here’s some further reading and more background on managed detection and response platforms).

    Why is MDR Important?

    Traditional managed security services (MSS) offer basic monitoring and alerting that do not provide the context and guidance needed to identify, respond to and remediate real security incidents. It leaves organizations exposed to many threats that pass through these basic services.

    How MDR Helps Protect Organizations

    MDR provides a proactive, outcome-driven approach that goes beyond the scope of what MSS vendors can offer. Common MDR services include:

    • Continuous network and endpoint monitoring.
    • Security orchestration.
    • Threat hunting.
    • Integrated response actions like remote threat containment.
    • Advanced MDR services also offer extended detection across clouds such as AWS, GCP, Azure and common SaaS suites like Google Workspace and Office 365. Other providers can protect incident command systems (ICS) and supervisory control and data acquisition (SCADA) systems within operational technology (OT) environments.

    What is DevSecOps?

    DevSecOps is a software development methodology that unifies previously disparate development (Dev), security (Sec), and operations (Ops) teams. It aims to integrate security across all development life cycle phases, including design, development, testing, deployment and delivery. It involves using automation to integrate security across all phases.

    In the past, security tasks were performed at the end of the development pipeline by a separate security team. Next, the product was tested by a quality assurance (QA) team. This approach worked when developers released software updates only once or twice per year. However, once software development teams adopted Agile and DevOps pipelines to reduce the development time, security became a bottleneck.

    How DevSecOps Improves Security

    DevSecOps integrates security into Agile and DevOps pipelines. It ensures teams can address security issues during the early phases of the development cycle. As a result, teams can apply fixes when it is easier and faster to remediate before products are released to production.

    DevSecOps makes security a responsibility shared by all teams, including Dev, Sec and Ops. It is no longer the sole responsibility of one team that creates a security silo. Instead, it enables teams to automate secure software delivery, prioritizing security without slowing down the software development cycle.

    How Managed Detection and Response (MDR) Solutions Benefit DevSecOps

    DevOps has revolutionized application development. However, due to the high velocity of modern development methods, they can introduce security gaps and flaws.

    In addition to regular security breaches occurring across the DevOps pipeline, new and sophisticated attacks, most significantly supply chain attacks infect the development systems themselves or third-party software components. This results in mega-attacks that can compromise millions of devices before being detected.

    How can MDR help?

    MDR is a relatively new cybersecurity offering but is beginning to have a major impact on companies seeking better protection with lower operational overhead. There are many overalls between MDR and DevOps. To integrate cybersecurity into production and deployment pipelines, some organizations are turning to a DevSecOps approach and MDR can help.

    DevSecOps makes cybersecurity an integral part of the entire DevOps life cycle. As more organizations implement DevSecOps, they can supplement the knowledge and security best practices of in-house teams with the security expertise provided by MDR services.

    How MDR Keeps DevOps Ahead

    MDR keeps DevOps teams ahead of the latest threats by keeping developers up-to-date on emerging threats and vulnerabilities and providing advanced tools for continuous security monitoring and response in their development and deployment pipelines. A key benefit of MDR is that it provides access to experts who can take action to prevent attacks, not just provide recommendations.

    MDR becomes a supporting element that allows developers to write more secure code as well as better secure their DevOps environment. With the help of MDR technology and experts, it becomes easier to identify advanced threats that can bypass security controls before they impact the DevOps environment or the resulting software product.

    Considerations for Selecting an MDR Solution

    • There are several important considerations when choosing an MDR platform suitable for a DevOps environment:
    • Understanding of attack surfaces common in a DevSecOps environment, and the ability to monitor and control the relevant environments.
    • Measures are taken to eliminate false positives and prioritize alerts. DevOps teams operate at high velocity and do not have time to wade through irrelevant alerts.
    • Automated triage and response at all stages of the development lifecycle. In earlier stages, this should take the form of actionable recommendations for developers, and in later stages, full incident response for production environments.

    All of this is useful as you find the right way to shift your organization to a true DevSecOps process.

  • 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.

  • The Problem With Security

    The Problem With Security

    As an IT professional with decades of experience at every level of technology and organizations—from cell phone prototyping to banking enterprise architecture, from entry-level to CTO—I can state definitively that I have spent an inordinate amount of time dwelling on and dealing with security. And I know I’m not alone. This is a common theme. You could almost make a sitcom out of it. “What are your developers doing?” Uhhh … writing code? “That’s security!” I could go on, hitting on everything from users to cloud instances and you could fill in the “That’s security!” punchline every time.

    That’s a problem. But not in the way you might think. I spent many years thinking I was somewhat unique in that I always rose to the occasion and approached security issues head-on. Most of the organizations I’ve worked for didn’t have dedicated security (I’ve probably written about that before), so some of us rose to the occasion.  Nowhere near all of IT, but enough to feel like we were protected.

    I now realize that I’m not all that unique; that more of us are doing the “learn security to be secure” thing than are not. I see it in modern organizations all the time. And I think that the real problem is this: Most of these people, like me, did not see themselves as security staff—but they are. Most organizations don’t recognize them as security staff—but they are.

    We’ve long harped on cultivating security recruits from this pool, and I’m now going to suggest that you go even further. Make these people part of your planning. If you know that person X on the ReallyCoolApp team is ferreting out security stuff, ask them to just send an email to update InfoSec once a week. Don’t make it a huge burden, and don’t try to force them into a pure security role if they don’t show the aptitude and interest (you really don’t want unwilling security staff) but make use of their talents and drive. Certainly, if this person is doing a good job of making certain ReallyCoolApp is mostly locked down and DevSecOps tools are running against it for a secondary validation, then your limited InfoSec resources can be directed elsewhere.

    Replicate this throughout the organization, and “That’s Security!” becomes a benefit rather than a hassle to try to lock down. You already do some of this—since the automation of passwords, most identity management is handled by operations staff, with security merely providing policy and being available to ops if needed. I’m simply suggesting that you expand this type of approach to include every IT department (and some non-IT departments in distributed environments). Don’t recruit everyone to be InfoSec, but recruit them to do a little bit of InfoSec in their area of specialty.

    People have always said “Security is everyone’s problem,” which is true, but it’s far too vague to be useful. This is a workable intermediate. “Security is every team’s problem” and recruiting the people on each team most interested in InfoSec to formalize their involvement is a better approach.

    And keep rocking it. We need security everywhere, because ne’er-do-wells have made everywhere a part of the InfoSec battleground. So recruit people everywhere without moving them from their current roles/responsibilities. Don’t let the sweet systems you’ve nursed through the years get whacked by attackers when a little recruiting and nurturing will fill the gap.

  • 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. 

  • 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.

  • What DevSecOps for SAP Looks Like

    What DevSecOps for SAP Looks Like

    In the past few years, organizations have seen a constant increase in cyberattacks targeting business-critical applications and the data within because that data is particularly lucrative to sell or trade. Organizations running SAP software, especially, are struggling, as SAP systems are complex and hard to patch—even worse, information security and cybersecurity teams often don’t understand SAP systems and how to secure them. Traditional security approaches aren’t enough to secure SAP systems, but DevSecOps for SAP could introduce a new approach with better results.

    What is DevSecOps?

    While traditional security often becomes a roadblock to accelerated software delivery. DevSecOps introduces a new security-first mindset that emphasizes security at every step of the software development life cycle and makes everyone in the organization responsible for security.

    DevSecOps includes all departments of an organization and embeds security thinking into the entire process, from the executive board down to individual teams. To make this successful, business operators need tools and processes that support:

    • Continuous monitoring
    • Scanning for security defects
    • Attack detection
    • Change management and governance
    • Regular assessments

    Why is DevSecOps for SAP Changing the Game?

    In the past, security was often neglected while implementing new projects or new feature releases under the assumption that security defects would be resolved later in an existing system by the information security team. This approach, however, introduced additional complexity, costs and business disruption.

    If security considerations are introduced in an earlier phase of a project, security defects can be identified and remediated much more cheaply and quickly. This alone makes it far more efficient and easier to resolve a potentially exploitable vulnerability. With good tools in place, this becomes very efficient and allows organizations to identify and resolve vulnerabilities that have been introduced in earlier iterations of their change processes.

    The biggest benefit, however, is that any new process or feature has been implemented with security by design, leading to a resilient environment that can more easily fend off cyberattacks.

    DevSecOps for SAP

    Here’s an example: Say a new business project is started with the intent to change SAP applications or processes to introduce new functionality. Like with any project, time, budget and available resources are key elements. For DevSecOps to work, important security considerations must be made in early phases of the project. In reality, every single project is a security project. This means that business requirements and targets must not be prioritized over security concerns. Processes and tools are needed to enable development and security teams to work together to answer important questions: Will the project introduce a security impact to contained data and established processes? Similarly, is there a need for additional software and security architecture, or is a specific skill set required that needs to be onboarded to the project?

    In an agile environment, once all epics and user stories have been written, the design phase can start. With a security mindset embedded into the project, this will automatically lead to a solution that is secure by design.

    During the implementation phase, developers need tools to scan for potentially vulnerable source code. 

    Identifying vulnerabilities that allow SQL injection, cross-site scripting or missing authorization checks early on in the development process makes it easier to fix them.

    The challenge here is that SAP does not provide the tools developers need to validate source code for security flaws. The SAP transport management system is vulnerable to software supply chain attacks unless appropriate security patches have been installed. For this reason, organizations need a code vulnerability analyzer that can be integrated within the SAP standard development IDE.

    In addition, quality gates enabled in the SAP transport management system can be very helpful for developers to avoid source code that lacks proper security validation.

    Functional issues discovered in the user acceptance test (UAT) phase must also trigger a restart of the validation cycle. Only when all security and functional requirements are met can production deployment be initiated. In this phase of the life cycle, DevSecOps for SAP focuses on monitoring to enable attack detection, regular (or better continuous) vulnerability assessments and accurate security patching.

    Which Tools are Needed to Introduce DevSecOps for SAP?

    While many organizations already make use of change management and IT service management solutions, they do not yet have all the tools needed to embark on a DevSecOps journey with SAP.

    Keep in mind there are platforms available on the market with an open API that allows integration within already established SAP solutions and provides the missing link between change management and security incident management. These solutions provide a one-stop-shop to securing SAP and reduce TCO compared to individual siloed tools for code scanning and vulnerability management.