devopsy.kinsta.cloud

Tag: breach

  • Benefits and Challenges of DevSecOps for Business

    Benefits and Challenges of DevSecOps for Business

    Almost every day, there is a new tactic or technique discovered that hackers can use to disrupt a company’s systems, obtain critical data and information or steal money. Often attackers look to exploit vulnerabilities in code to carry out their attacks. Ironically, it’s usually a small piece of code that helps a business perform very simple tasks that can become the root of this serious issue (e.g., logging, report service and glue for application). In fact, it only takes one exploitation, vulnerability or human error to cause a data breach that, on average, costs $4.35 million. Some experts projected that by 2025, these breaches could cost a total of $10.5 trillion. Therefore, CEOs and other corporate executives should reflect on these incidents to ask themselves what would happen if someone entered their systems to exploit code and what it could mean for their company.

    The Problems That a Business Faces

    In traditional development practices, security serves a ‘gating’ function. Security checks are performed prior to releasing an application to production and, if issues are found, security stops rollouts. This can have disastrous ramifications.

    The unknown can be frightening, but that’s where DevSecOps can help. DevSecOps incorporates security into every step of the software development life cycle (SDLC) from requirements to architecture and design, coding, testing, release and deployment. By automating and integrating security practices into the software development life cycle, development teams can react to vulnerabilities sooner, automate security checks and proceed into production with a more reliable and secure product.

    The benefit is felt when a tactical vulnerability is discovered and the DevSecOps practice is already in place to ensure that it can be remediated with limited impact on the business.

    The Business Benefits of DevSecOps and Best Practices

    Streamlining the SDLC and including security checks (often automated) in the process early in the development cycle can identify a problem before it can negatively affect the bottom line of the development effort and the business. Having a vulnerability remediated early in the development cycle is an order of magnitude less expensive than one discovered just prior to production.

    DevSecOps works best in an organization where Agile practices have been adopted to swiftly enable continuous integration, deployment and scalability. The road to streamlining and automating these practices can be long, but when effectively applied, DevSecOps best practices reduce costs for the company and accelerates time to market.

    For DevSecOps to be effective, security must have a seat at the table when requirements are gathered and architectures are planned. This integration of work practices ensures that risks are identified early and can be mitigated well before an application is launched in production.

    Using that same connection with operations, security procedures should be established to feed new vulnerability discoveries into the pipeline for remediation. However, implementing DevSecOps isn’t a magic fix and it won’t happen immediately. But why can it be so hard to implement?

    Overcoming the Challenges of DevSecOps

    There are many difficulties when it comes to implementing DevSecOps. Here are two of them:

    1. Cultural Shift:
    Leading with a DevSecOps approach requires a huge culture shift within the organization that challenges the way many departments operate today. Many employees might find it difficult to drastically change what they’ve been doing for years. Another roadblock is the belief that better protection slows down processes and restricts innovation. Quick code production is a goal for developers who want to meet the demands of businesses, while on the other hand, security teams are focused on making sure the code is secure.

    Thorough training for both security and development experts will help overcome some cultural obstacles but integrating the goals and objectives of both teams will push the adoption of DevSecOps practices. Organizations will begin to see security align to faster time and flexibility of solutions while developers will begin to adopt a security-first mindset.

    2. Complex Tool Integrations:
    Most DevOps toolchains are produced by different vendors. Teams select source code management, continuous integration/delivery (CI/CD), build tools, binary libraries, code review and problem monitoring solutions based on their unique needs. Adding security tools into that pipeline can create a challenge for ensuring the best results for both teams.

    Security analysis in the development pipeline is done with tools that perform software composition analysis (SCA), static application security testing (SAST), and some form of dynamic testing. Integration into the pipeline of these tools is significant and creates difficulties for developers. The developer must know the intent of the scan and what to do with the problems they uncover. It is important that developers have an accurate understanding of where the problem arose and what the issues mean. However, combining and comparing the results and data of many vendors’ resources might be challenging.

    The best course of action would be to consolidate your solutions. This will not only make things simpler for the developer and the organization, but it may also reveal threats that the organization wasn’t previously aware of.

    Overcoming these obstacles is not an easy task, but it is possible. Once a DevSecOps approach is accepted and fully implemented across your company, you can expect code to be developed with fewer bugs and security risks. The cost of deploying code will also eventually decrease, and at a pace that helps the organization maximize its return on investment. Overall, systems created within this process will be significantly more flexible and capable of adjusting to modern-day threats and change in the midst of a digital transformation.

  • The Uber API Authorization Vulnerability

    The Uber API Authorization Vulnerability

    What Happened

    In September 2019, a critical bug was discovered on Uber API, which allows merchants, service providers and others to offer ride-sharing services to customers. Uber had exposed a vulnerable application programming interface (API) endpoint that allowed attackers to steal valuable data, including personally identifiable information (PII) records and authentication tokens of riders and drivers. The leaked authentication token could be used to perform a full account takeover.

    Luckily for the company, the vulnerability was discovered before harm could be done. But the case is an example of where traditional security systems can fail to find potential threats because they lack the business context for the application’s logic. Let’s take a closer look at what happened and the implications.

    Technical Details

    When a new Uber driver joins the platform through a referral link, their browser communicates with the API host  “bonjour.uber.com”. The registration process triggers an API call to the API endpoint of:

    POST /marketplace/\_rpc?rpc=getConsentScreenDetails

    The API receives the “userUuid” parameter from the client and returns details about the user. This information is used to populate the consent screen on the client-side:

    As part of a legit flow, the user should send only his own user ID.

    The API endpoint is susceptible to two types of API vulnerabilities:

    • BOLA (Broken Object Level Authorization). Because the program didn’t validate that the client who sent the request had access to the user represented by the user ID parameter, the client could access data of other users by changing the user ID.
    • Excessive Data Exposure. The API response contains a large JSON object with all the user’s details. The API returned this information, even though the client didn’t use it.

    Why Current Security Solutions Can’t Detect This

    When we look carefully at the exploitation flow, we find the attack involved a very subtle change in the API call, replacing one user ID with another. In order to detect such a small change in the traffic, a deep understanding of the business logic of the app is required.

    Current security solutions in the market lack that understanding, usually acting on the context of a single HTTP request. They don’t deeply understand important components of the application that are required to detect BOLA and other authorization vulnerabilities.

    How Traceable AI Solves the Problem

    The Traceable Defense AI approach to detect API attacks is very different than other security solutions. In a nutshell, it observes the data as it is passes through the API and the microservices of the app. It then uses machine learning algorithms to discover the application’s business logic, providing full visibility into the users and their roles, the API endpoints they communicate with, and the resources that the endpoints interact with behind the scenes.

    This methodology allows Traceable to create a baseline of what a legitimate user’s flow looks like, and hence to detect the most sophisticated and subtle API attacks, including BOLA.

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!

  • 2014 – The year of identity security breaches

    2014 – The year of identity security breaches

    There’s no doubt that 2014 will be remembered in the IT industry as a year of major security breaches.

    The year started with virtually every US resident worrying whether they’d been affected by the Target breach, and ended with the massive security breach of Sony and their film “The Interview.” And was, all along the way, peppered with other notable breaches.

    The interesting theme, with all of the major security breaches, was that they were almost all related to compromised credentials. As we know, having the right privileged user management is one of the top ways to protect your network, you don’t want to share same hacker-limelight that Sony did.

    But just for posterity, here’s a review of some of the top security breaches, and how they happened:

    Target

    What is considered the “biggest retail hack in history,” shook nearly every US resident in early 2014 as credit cards from 1,797 stores were compromised around Thanksgiving 2013. The hackers plotted against the company while Target was installing new security software. The repercussions were severe. Target reportedly spent $61 million on legal damages instigated by the breach, and profits fell by 46% in the holiday shopping season.

    Suggested read: http://www.businessweek.com/articles/2014-03-13/target-missed-alarms-in-epic-hack-of-credit-card-data

    Sony

    Although the investigation into what occurred is still on-going, early accounts point to compromised user credentials (or even perhaps an inside actor providing credentials) being leveraged to access, gather and exfiltrate data. We know, of course, that the attackers gained a tremendous amount of data including unreleased films, personal emails, HR data, and other confidential documents. Bummer for Sony. The WSJ estimates the breach cost them $100 million.

    Suggested read: http://techcrunch.com/2014/12/16/hack-sony-twice-shame-on-sony/

    Celebrity iCloud Photo Hacking

    While this particular breach was extra-sensationalized because of all of the celebrities involved, the Celebrity iCloud hack boiled down to plain old identity theft. Hackers identified email address, passwords, and the like and started gaining access to the iCloud data. Once in, they were able to copy all of the files. When celebrities realized they couldn’t login to their iCloud accounts, they naturally reset their passwords and were able to continue. Most of them didn’t even know they had been compromised.

    Suggested read: http://www.cnn.com/2014/09/02/showbiz/hacked-nude-photos-five-things/

    eBay

    In late May, eBay notified its customers: it had been compromised. Credentials for employees with access to their critical systems were compromised, is appears, several months prior to their detection. Financial information, which was coyly stored separately, was not hacked. Lucky for eBay.

    Suggested read: http://www.forbes.com/sites/gordonkelly/2014/05/21/ebay-suffers-massive-security-breach-all-users-must-their-change-passwords/

    Home Depot

    Over 56 million credit cards and 53 email addresses were stolen after a third party vendor’s employee’s credentials were stolen. This allowed hackers to gain access to the Home Depot network and make off with the confidential data. This breach was reminiscent of the Target breach in which another third party vendor (HVAC provider) was compromised and that subsequently led to Target’s compromise.

    Suggested read: http://www.usatoday.com/story/money/business/2014/11/06/home-depot-hackers-stolen-data/18613167/

    As you can see, the common thread to these security breaches is compromised credentials. Hackers realize the power of admin credentials in leveraging open systems. And, because many companies do an inadequate job of protecting their systems—despite patching, hardening, and firewalls—user admin access becomes an easy hacker target.

    How can we stop this seemingly simple vector of breaches? Protect your credentials with good user management. Just patching isn’t going to get us there. At Jumpcloud we spend a lot of time looking at this, and ensure that security and user credentials are watched with close vigilance and best-practice security to keep hackers out. Drop me a comment if you have any other thoughts on this topic.