The Application Security Podcast — Security beyond vulnerabilities

Archive for the ‘Application Security’ Category

The Application Security Podcast — Security beyond vulnerabilities

Posted by Wolf Goerlich

“Wolf joins us to talk about some security things that will stretch your mind, like security beyond vulnerabilities, how apps intended functionality can be misused, data privacy, and nudges and behavior science. Wolf challenged my thinking in this episode and pointed out a new area of threat modeling I had never considered. We hope you enjoy this conversation with… J. Wolfgang Goerlich.”

 

Have a listen here: https://www.youtube.com/watch?v=oZe0Sp9JU3s

To see listen to other podcast interviews, click to view the Podcasts page or the Podcasts category.

 

Security is not the control, it is the context – Design Monday

Posted by Wolf Goerlich

Seeing is Forgetting the Name of the Thing One Sees. A fantastic title, right? I was having a coffee meeting with a new product designer a few months back. As can happen, I was pretty wound up, going on about the need for usability and human-centric design in cybersecurity. She told me, “you need to read Seeing is Forgetting the Name of the Thing One Sees.”

The book covers conversations Lawrence Weschler, the author, had over three time periods with Robert Irwin. It gets to the heard of Irwin’s philosophy and approach. Irwin began abstract in the 1960s. He painted lines. He painted dots. But when displaying his work, Irwin noticed the way the art was experienced was influenced by factors outside of his paintings. Any of us who have seen optical illusions with colors and lines understand this instinctively and likely think nothing of it. But to Irwin, who was obsessed with the experience to the point of banning photography, this simply wouldn’t do. Irwin took to replastering and repainting walls, sometimes whole studios, where his art was displayed.

Robert Irwin insisted on controlling the entire experience and this led to the realization that the surroundings were just as important as the artwork itself.

We’ve been slow at coming to a similar realization in cybersecurity. Consider the Web application. A thousand things have to go right for it to work, and a thousand things can go wrong from a security perspective. OWASP framed these issues up into a top 10 list. This simplified the work of developing a secure Web app. However, OWASP initially focused solely on the app itself.  Of the six releases since 2003, only the last two releases included the walls and studios, the vulnerable server components, on the OWASP top 10. We’re slow to recognize the importance of the surroundings.

Robert Irwin’s obsession with the surroundings transformed the artist from painter to landscaper. He has gone on to produce more than fifty large scale projects since 1975.

From the perspective of a designer, we must consider how the new capability fits into the existing cybersecurity portfolio and, more broadly, into the organization. We have to replaster the walls. We must make sure it fits in the studio. From the defensive perspective, this makes a lot of sense. A criminal faced with a strong control will look at the environment for other weaknesses and take advantage of gaps. From the usability perspective, Robert Irwin reminds us that how something is seen is as much about the thing as it is about the overall experience.

Security is not the control itself. Security is the surroundings.

Robert Irwin’s Double Blind exhibit at the Vienna Secession, Austria.
Photography: Philipp Scholz Ritterman

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

With continuous security, Sec DevOps deconstructs CI/CD

Posted by Wolf Goerlich

Nothing is set in stone when an organization follows a DevOps methodology — a DevOps security model pushes developers and ops to constantly retune, slow down and speed up.

Excerpt from: With continuous security, SecDevOps deconstructs CI/CD

“All of the DevOps teams I work with have some integration between cybersecurity and development,” said J. Wolfgang Goerlich, cybersecurity strategist at Creative Breakthroughs Inc., a Detroit-based IT security consultancy. Some organizations have embedded security architects in the DevOps teams. Others have security champions within DevOps who work directly with the cybersecurity team. “In both cases, the partnership is a means to introduce security concepts while maintaining DevOps velocity,” he said.

Goerlich said roughly one in four DevOps teams integrate and automate some level of security controls. “This integration is generally performing scans and checks against the static code, the application, and the underlying environment composition,” he said.

But this level of automation often requires tuning and adjustments to ensure it keeps pace with DevOps. For example, he said, traditional code-level scans take several days. “That’s not effective when DevOps is changing the code on a daily or even hourly basis,” Goerlich said.

Effective SecDevOps teams secure without slowing, and they add continuous security without exceeding the team’s capacity to change, he said. “It’s paradoxically fast and slow, with security controls being added slowly while tuned to execute very quickly.”

Success comes from balancing protection for the DevOps product while protecting the DevOps productivity.

Read the full article: http://searchitoperations.techtarget.com/feature/With-continuous-security-SecDevOps-deconstructs-CI-CD

This post is an excerpt from a press article. To see other media mentions and press coverage, click to view the Media page or the News category.

Starbucks gift card fraud

Posted by Wolf Goerlich

Starbucks is in the news as criminals abuse its online services through fraudulent gift card purchases. On the surface, the issue appears to be about consumers’ passwords and the poor practices around their use. There is more to the story, however, and I would argue two deeper concerns are the real issue. The first is in how emerging payment systems are monitored and secured. The second is in how online services are developed and maintained.

The Starbucks security hole is simple enough. The criminal breaks into the coffee-loving victim’s account by guessing their password or using the password reset features. They then load a Starbucks gift card using the victim’s stored payment information, and transfer that card to themselves. This is usually automated so that several gift cards can be filled and stolen in a short period of time. The attack normally ends only when the victim receives notices on the gift cards and resets their Starbucks password.

Starbucks reportedly processed $2 billion in mobile payments last year. That’s a serious amount of business that requires a re-adjustment of their risk appetite to reflect the target their business has become. Moreover, as retailers and emerging payment systems develop bank-like functionality (funds transfer, cards), they need to start thinking more like banks. Anti-fraud techniques such as behavior monitoring for unusual activity is a prime example. Another is offering consumer protections such as reimbursements (at this point, Starbucks defers consumers to work with PayPal or their credit card company.) When transactions are into the billions, it’s time for mobile payments to offer credit card equivalent security for consumers.

The other aspect of consumer protection is the online service itself. In , threat modeling is one of the first steps. The goal is to look at the functionality being developed and to identify ways it could be abused. With this in mind, security and privacy requirements can be defined. After Starbucks built their services, they could have performed scenario-based penetration tests to ensure the controls met the requirements, and the requirements prevent the threat. Given that gift card fraud is well known and that the controls in place are lacking, it’s clear that Starbucks did not complete these steps as part of their development program.

In summary, yes, consumers need to watch their password hygiene and monitor their accounts. But there’s more to the story. As companies build online services that handle billions in payments, they must mature their processes in handling fraud and building applications. We need credit card equivalent security for transactions. Developers need a secure development lifecycle for preventing their services from being abused. Starbucks is today’s example of organizations falling short on both areas, and leaving the consumers with the tab.

Cross posted from: http://content.cbihome.com/blog/starbucks_giftcard_fraud

Securing The Development Lifecycle

Posted by Wolf Goerlich

One line. Ever since the Blaster worm snaked across the Internet, the security community has known that it takes but one line of vulnerable code. Heartbleed and iOS Goto Fail made the point again last year. Both were one line mistakes. Even the Bash Shellshock vulnerability was made possible by a small number of lines of code.

Let’s put that in perspective. Today, our thermostats have tens of thousands of lines of code. Our cars have hundreds of thousands and our operating systems have millions. The industry standard for quality is 0.69 defects per 1,000 lines of code. Any one of those defects can lead to the next Blaster or Heartbleed. And it only takes one.

To manage the risk of code-level vulnerabilities, many organizations have implemented security testing in their software development lifecycle. Such testing has touch-points in the implementation, verification, and maintenance phases. For example, an organization might:

Implement. As the code is produced and checked into source control, run static application security testing (SAST) with HP Fortify Static Code Analyzer. This identifies vulnerabilities and allows them to be corrected during development.

Verify. As part of the final quality assurance checks, perform dynamic application security testing (DAST) with HP WebInspect. This identifies security concerns in the running software. Some organizations go so far as to integrate their QA scripts with the DAST processes.

Maintain. Through-out the lifespan of the software, perform periodic audits with SAST and DAST to ensure that defects are not introduced through maintenance or that new vulnerabilities are not discovered.

This example approaches security as a quality management concern with routine checks and gates. With SAST and DAST, along with other activities during the development lifecycle, organizations reduce defects and manages the risk of software exploitation. The toolset for these tasks has matured to the point where program management is now possible; including scheduling, tracking, communication, metrics, and more.

Moreover, the tooling must be easy to use and fit within the development workflow. It must be stood up in a way that is usable by the development team. Good security is usable security. The success of a tool depends upon the adoption and implementation.

Managing a security program is more than tooling, of course. There are other manual tasks to perform, primarily around requirements and design. These include establishing security requirements, threat modeling, security architecture, and performing manual application penetration testing. Mature programs will contain all these touchpoints and more. Yet significant risk reduction can be made simply by beginning down the path towards a full secure development program.

In sum, take any code base. How many lines of code does it have? Given the standard defect density, how many possible defects are there? Take a moment to run SAST and DAST. The results may be surprising, if not downright scary. Thankfully the solutions and processes exist to find and secure that one line of code.