devopsy.kinsta.cloud

Tag: software defects

  • Scrutiny of the Bug Bounty

    Scrutiny of the Bug Bounty

    Tips on building an internal bug bounty program

    As a programmer, have you ever felt pressured to ship a release with lots of new features, while you knew that there was still a technical debt stability improvements and bug fixes that you wanted to address but didn’t have the time or scope to address? This happens all the time, along with the worry that a bug could cause problems for users leading to churn, revenue and reputation costs. Even the best software faces this challenge, balancing road map velocity with software stability, with each release. These imperfections can delay new software and feature releases at a time in which speed has become a powerful competitive advantage.

    Developers and their organizations are challenged to bring products to market faster without impacting their stability and reliability. To be successful in this regard, organizations need a culture and resources to detect instability at multiple inspection points.

    Enter the Bug Bounty

    Of course, development teams are responsible for the quality and stability of the products they build. But those products often act differently in distinct environments. This problem isn’t new. Developers have always faced unknown issues prior to a release. However, dealing with such problems can be improved by considering the cultural solutions and tools used to reduce the bugs and increase stability.

    Many organizations are creating internal bug bounty programs to promote security and application stability by reducing software bugs. These organizations promote a proactive culture of ownership and empowerment through internal programs that allow a variety of employees to assume the role of bug hunters. If the proper tools are available, bug detection responsibilities can be shared by development teams, operations and executive management.

    Bug bounty programs enable teams to harness problem-solving skills to reduce bugs in application and software releases. Detection tools enable multiple teams to track and prioritize bugs that have the greatest business. This involves multiple teams and viewpoints in tracking and fixing bugs to prompt a variety of strong ideas and solutions.

    A companywide bug bounty program can also promote awareness by involving participants outside the development process in a fun and challenging way. It creates an opportunity for people throughout the organization to improve product quality. It’s a good way to promote application stability awareness while encouraging employees to explore applications and software development.

    Internal teams of engineers and developers are inherently well-suited for these types of projects because they know the infrastructure better than anyone, including its strengths and the weaknesses. By codifying the internal search for bugs, organizations can learn from mistakes and strengthen products while building intellectual capital. An internal program has the added benefit of identifying vulnerabilities before customers or users experience them.

    How to Begin

    To launch a successful program, consider the nature of the program along with the process and workflow for prioritizing where to allocate team resources. Specifically, an organization must define the business objectives that determine the kind of program you want to run, what the rewards will be and the scope of what will be tested. And with that information, determine the culture and tools that make it all possible.

    It’s important to keep in mind that the two pieces (culture and tools) are not exclusive and don’t have to come in a certain order. You can use the right tools to build the culture, or you can create the right culture and right tools help codify and amplify that culture.

    Considerations for a Successful Internal Bug Bounty Program

    Business Objectives

    What are the business goals and objectives that determine how the program is administered and what solutions will be used to achieve your desired outcomes?

    Rewards

    To attract the talent and attention needed to run a successful program, setting the rewards in line with your business objectives is an important step.

    Scope

    Detailing the scope of the program is essential to specify what the program intends to investigate, where to explore and what measures are allowed.

    The more detail that can be supplied the better.

    What Participants Need to Know

    Internal teams need to know what they are signing up for when they choose to participate in the program and how anything they uncover will be utilized. Be clear for all involved, both the organization and the program participants.

    It is crucial to point participants in the right direction and establish boundaries around where activities are expected and allowed and where they will be most beneficial. One tactic may be to keep a running list or dialogue detailing important targets. These targets will likely be a mix of web, mobile, IoT and API and can be prioritized in running lists.

    Once acceptable targets are established, the best way to achieve a lasting impact is to have the tools in place that allow teams to build better software. Through culture and tools, it’s important for teams to be empowered to capture errors and diagnostic data in any app, prioritize the errors that have the greatest business impact, reproduce and offer fixes for the errors, all in clear metrics that multiple teams can understand and put to use.

    Finally, ground rules are needed. This step will vary among organizations based on objectives and scope. But programs should detail how tests can be carried out, who specifically is authorized conduct them and how adjustments will be communicated as the program evolves.

    Businesses may find many reasons for implementing an internal bug bounty program ranging from security to quality and even professional development. Whatever the reason, take the time to define the program clearly to keep it within the scope of your goals and pay close attention to the culture you promote and the tools that are implemented to be sure the program can achieve maximum results.

    — Chuck Dubuque

  • The Cost of Not Building with Security in Mind

    The Cost of Not Building with Security in Mind

    The unfortunate reality for today’s organizations is the fact that a security breach is bound to happen. Major breaches are happening with alarming frequency and fill the news headlines almost daily. And behind many of these major breach stories is a software vulnerability that has been exploited. There is a silver lining, however. Addressing security at the development stage can help organizations “get upstream” of certain issues, which goes a long way toward alleviating potential breaches.

    Now there are always two sides to every coin, and this is where companies need to weigh the costs of not taking a proactive approach to making security a key part of their software development process. Is the upfront time and effort worth it when it comes to developing software and ensuring bugs and vulnerabilities are addressed before it is put into the wild? The simple answer is, yes! We are already seeing this in certain industries such as financial services, which learned the hard way that it is a critical component of software development—mitigating risks and significantly lowering the financial burden associated with a major breach.

    In fact, security should have been more central to software development a long time ago. As software, and more broadly technology, continues to evolve and permeate our lives from more angles, it is crucial that security be a consideration—a “use case” as developers call it—from the earliest conceptual stages of a project. The costs of not doing so are simply too painful to imagine otherwise.

    Shifting to Security-First

    To build more secure software, organizations typically must implement a software security initiative. You can break it down into four steps:

    • Assess your current software assurance posture
    • Define the strategy your organization should take to ensure a viable posture
    • Formulate a road map of how to achieve that posture
    • Implement your strategy

    The above steps are simple and when you think of the alternative to not doing this, adding security as a pivotal part of the software development process seems like a no-brainer. To better understand what I mean, you need only look at the cost the average breach has on an organization. According to the 10th annual “Cost of Data Breach Study” independently conducted by Ponemon Institute, the average consolidated total cost of a data breach in 2015 was $3.8 million, an increase of 23 percent from 2013. The study also reported that the cost incurred for each lost or stolen record containing sensitive and confidential information increased 6 percent, to a consolidated average of $154 from $145. Depending on how much data has been compromised, the financial fallout can be staggering, if not crippling, to an organization.

    Conversely, the cost to repair a single vulnerability in an application during the design phase is less than $500, according to the IEEE Computer Society. The fact that the financial impact of not addressing security during the development process can quickly become cost prohibitive, is a clear indication that secure software development practices can no longer be overlooked. Breaches are now a boardroom issue and require a seat at the development table.

    As we can see from the stats above, the economic fallout for organizations is obvious, but with the Internet of Things coming to a house near you, this issue is suddenly becoming more personal and painful for the average person. Whether an attacker takes over your thermostat from Russia or finds a way to monitor your home via your baby camera, vulnerabilities are making it easier for malicious actors to corrupt corporate, government and now individual networks like never before.

    We are well beyond the “it will never happen to me” phase. Breach stories that used to happen to so called “other” people are more likely to happen to you if software defects continue to be ignored and are not fixed when they should be. No matter how you crunch the numbers, if security isn’t addressed at the software development level, the result will always end in a costly lesson learned.

    About the Author/John Dickson

    John Dickson_HeadshotJohn B. Dickson is an internationally recognized security leader, entrepreneur and Principal at Denim Group, Ltd. He has nearly 20 years hands-on experience in intrusion detection, network security and application security in the commercial, public and military sectors.

    Dickson is a popular speaker on security at industry venues including the RSA Security Conference, the SANS Institute, the Open Web Application Security Project (OWASP) and at other international conferences. He is a sought-after expert and regularly contributes to Dark Reading and other publications. A Distinguished Fellow of the International Systems Security Association, he has been a Certified Information Systems Security Professional (CISSP) since 1998.

    As a Denim Group Principal, he helps executives and Chief Security Officers (CSOs) of Fortune 500 companies and government organizations launch and expand their critical application security initiatives.

    Twitter: http://twitter.com/johnbdickson
    Linkedin: https://www.linkedin.com/in/john-b-dickson-cissp-41a149