With continuous security, Sec DevOps deconstructs CI/CD

Archive for the ‘Application Security’ Category

With continuous security, Sec DevOps deconstructs CI/CD

Posted by

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 more here:

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

 

Starbucks gift card fraud

Posted by

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

Starbucks gift card fraud

Posted by

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.

Read the rest at: http://content.cbihome.com/blog/starbucks_giftcard_fraud

Securing The Development Lifecycle

Posted by

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.

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 …

Read the rest at http://content.cbihome.com/blog/securing-development-lifecycle