devopsy.kinsta.cloud

Category: DevSecOps

Lance Crosby’s Vision To Bring Scale, Speed and Security To Developers with StackPath

The last most of us heard from Lance Crosby we thought he was riding off to an island sunset, to bask in the glow of a very successful exit from SoftLayer. The company he founded was bought by IBM for a few billion dollars to serve as the centerpiece of their cloud strategy. Many would have been content with that as their career. But Crosby isn’t done yet. His new vision is StackPath, whose mission is to bring scale, speed and security to developers.

I had a chance to catch up with Lance recently and talk about StackPath. The company just emerged from stealth in July but already has over 100 employees and over thirty thousand customers. This is due to acquiring three companies pre-launch, “MaxCDN, a leading NextGen CDN company, Fireblade, an Israel-based company with patented cloud based WAF technology, and Cloak, a leading VPN technology company.” On top of this StackPath has developed some patented new DDOS mitigation technology. Of course DDOS attacks are all the rage now with everyone’s camera, refrigerator and any other connected device in on the action.

From a DevOps point of view what I find interesting is that Crosby and StackPath have clearly targeted the developer, rather than the security admin or the Ops team with this offering. Even in the title of their press release announcing the StackPath platform and CDN they target developers, “StackPath Announces General Availability of Its Global Security Platform for Developers.”

This is an interesting approach and one I spoke to Lance about. In Lance’s view there is a gap between those who build and design applications and those who operate and secure them. Empowering developers with a friction-less security solution is what StackPath’s mission is. It is the developers who need to be thinking about security and more importantly making it part of the equation. This idea is one that many in security have espoused, but usually because they feel developers have larger budgets than the security team. But I don’t think that is the case here. Crosby knows both the security and developer markets from SoftLayer. He is trying to fill a need he saw while still at SoftLayer that he wasn’t able to offer then.

The CDN service they announced wraps up the three technologies they acquired along with their DDOS mitigation. To me it seemed like a Cloudflare kind of offering. Crosby agrees that there are similarities, but the plan is to build out the platform far beyond what it offers now or what Cloudflare offers. Threat analysis and artificial intelligence are part of the future, as well as more.

The company already raised a large first round led by ABRY Partners, a multi-billion dollar private equity fund. Of course Crosby has his own money available as well as no shortage of VC/private equity funds who would like to invest in his next adventure based on the success of SoftLayer.

The security industry has been looking for cloud native, next generation solutions and StackPath could be one of these. At some point though you need to please multiple masters. In this case if you are going to sell developers security, at some point you need to get the security people on board as well. It will be interesting to see how StackPath continues to grow and expand in the market. Certainly a mix of organic solutions with a sprinkling of acquisitions appears to be the recipe Crosby and team are following.

— Alan Shimel

November 2, 2016
DevOps Lessons from the Dyn Attack Fiasco
Dyn’s DNS servers suffered a major DDoS attack last week, slowing a host of major websites. Does the drive for DevOps automation increase the risk of similar attacks? Maybe, but it doesn’t have to.

As almost every geek knows by now, a DDoS attack on Oct. 21 overwhelmed Dyn’s DNS servers, and websites that depended on those servers slowed to a crawl. The attack was made possible because a large number of Internet of Things (IoT) devices were compromised using Mirai, a malware tool that breaks into devices using default access credentials.

While it’s not yet clear exactly why so many IoT devices were configured with default login credentials, it’s likely that at least part of the reason included the following factors:
- IoT devices are so numerous that securing them all is very difficult, especially when they are configured with weak security out of the box.
- The need to give multiple users access to the devices encouraged installers and service providers to keep the default credentials in place. For example, if you have a smart thermostat that is installed by a contractor, managed by a utility company and owned by a homeowner, each of those parties could potentially need access to the device. Sticking with default login credentials is a lazy but effective means of providing it to all of them.
In certain ways, the shift to DevOps makes challenges like these more common. Consider the following:
- DevOps encourages the use of microservices. That means more services and logins to manage. It increases the risk that some services will not be secured properly because default login credentials will remain in place.
- Under DevOps, the entire software delivery team is supposed to have access to all platforms and resources that are part of the delivery chain. That’s different from waterfall development, in which developers only had to be able to access developer tools; IT ops only needed to access management tools; and so on. The need for broader access could encourage teams to take the easy way out by using default logins—or even just sharing login information, which is risky even if the credentials are not the product defaults.
A shorter way of saying this is that to increase agility, DevOps increases complexity. Greater complexity translates to more potential security risks.

Conclusion

The Dyn attack was not a DevOps problem, and none of the above means that securing a DevOps environment is not possible. It is, but it takes more work.

Still, the Dyn outage is a reminder of just how badly things can go if developers and admins make mistakes such as relying on default login credentials. This challenge will become more difficult, not easier, as DevOps continues to reshape the way software is written and deployed.

— Chris Tozzi
October 25, 2016
Network Resilience and Security from A to Z

An observer watching a bunker shot by legendary pro golfer Gary Player was heard to say: “I’ve never seen anyone so lucky in my life.” The player retorted: “Yes, and the more I practice, the luckier I get.” Yet, when it comes to cybersecurity, nearly half of organizations are solely relying on luck to get them through a cyberattack.

There is not enough practice or training in terms of incident response, and testing happens haphazardly depending on the developer and organization—obfuscating baselines and the context necessary to ensure security and resilience. Particularly in terms of testing, we’ve noticed that despite awareness of its importance, bugs and vulnerabilities routinely slip through. In fact, a recent Ixia survey found that 34 percent of developers have deployed products that have had a few bugs. Worse, 31 percent said products harbored significant vulnerabilities that required patching later in the cycle when shipped.

The problem has been exacerbated by the rapidly growing normalization of agile development processes. Groups of developers are tasked to build products piecemeal, leading to application development that is often incremental and happens in iterative cadences. Testing and oversight happen at each step of the process, but the segmented nature of the development cycle means that bugs and vulnerabilities often arise when the code is assembled, and are routinely missed. For instance, the average IT web application had 32 vulnerabilities, according to recent WhiteHat Security report. It’s clear that more than a local test—a comprehensive end-to-end test—and relevant training are critical.

A Change in Culture

Improvement begins by changing the culture that minimizes security testing for the sake of launch timelines. Too often, the product development team will come together just to be told they need to move up their release date. The habit results in products that walk a thin line of performance, as they may contain unknown security holes due to not being fully tested. Just consider the slew of IoT devices and services that have been proven to be vulnerable because of this habit—from cars to coffee machines to cameras. It’s a major reason for security incidents, even with multiple layers of security tools.

This also requires the right training. Having seemingly secure code and the right security measures is not enough for a strong security stance if proper training is not implemented. Organizations need to learn how to respond. Yet, recent SANS Institute research into the incident response capabilities of companies worldwide found that 43 percent of respondents did not have a formalized incident response plan, and 55 percent didn’t even have an incident response team.

This less-than-vigilant approach to system-level security can have worse implications once a product goes live in the network. For instance, updates, patches and configuration changes applied when a new feature is added can reset an organization’s security posture, and this sometimes goes unnoticed—leaving gaps for threat actors to exploit. Or sometimes a machine fails to update and becomes and entry point, as experienced by JPMorgan Chase. Continuous testing and training from the very onset of operation and throughout a tools lifespan are imperative for all employees, especially IT and security pros—even in its simplest iterations.

What to Look For

Successful and continuous testing and training expose security and IT pros to anomalous activity they’d not be able to recognize otherwise. It’s necessary to be able to answer questions such as, “What does suspicious activity look like on my network?” or “What security alerts require immediate action?” The more they see, the more refined their eye becomes—it’s all about a proactive approach paired with repetition.

Which raises the question, what is considered a good test? It starts with accurately reflecting the widest range of attack types in live operation. It is also important to create an accurate sandbox to test in so that it can be as close to reality as possible. The more accurate the environment, the better prepared IT and security teams will be. Realistic depictions better prepare employees as new malware, phishing and DDoS attack types emerge every day—not to mention it helps keep up with evolving typical application behavior.

More specifically, function and system testing should be at the heart of any program following the development cycle test process. Quality of service, performance and resilience all benefit, along with security, as a result.

Some companies take shortcuts, such as using internally generated attacks or crowdsourced probes to attack their networks. Just as bad, some have the development team create and run their own test scenarios. While this can give the illusion that everything is good, it creates a false sense of security—a single scenario only protects you from one type of attack.

The key is not to stop at the minimum when it comes to security testing and training. Developers spend lots of time building great features; why not spend time training teams on how to use them? Limited or biased tests can easily overlook glaring flaws.

Ultimately, the right approach to testing can make networks robust and prepare IT teams for real-world attack situations, helping minimize response times and the negative impact on the business. As breaches now seem to be coming from every direction, testing needs to come to the foreground, from the development stages to when products sit directly in the line of fire.

About the Author / Jeff Harris

Jeff Harris is VP, Solutions at Ixia, leading solutions marketing for Ixia’s security portfolio of products and capabilities. As a former product development leader of advanced networking, communications, and surveillance products for commercial and military applications, Jeff has a deep appreciation for security implications that occur in development and operation. Jeff has led first to market product teams in personal area networks, mobile ad hoc networks, and a wide range of surveillance equipment and platforms. Connect with him on LinkedIn and Twitter.

September 30, 2016
Empower Developers to Build Security into DevOps

Over the past 10 years, as more organizations have made the transition to DevOps, there has been a cultural shift in which security and development teams agree quality is a priority. Yet, even with a shared quality focus, Development, Security and Operation teams still find themselves at odds on the road to continuous delivery of secure software.

Some people claim developers don’t care about security. The reality is they want to write great code that’s secure code, but often they don’t have access to tools that fit with the way they work.

There’s also tension between different sets of expectations and performance metrics for different teams. Developers are graded on their ability to deliver features and functionality to market as quickly as possible, while security engineers focus on prevention and detection. Operations teams, meanwhile, focus on reliability, uptime and stability.

Development managers feel pressure from senior management to avoid project delays. At the same time, security managers aren’t rewarded for reducing risk and may be asked to turn a blind eye and give the application a temporary pass so the project can move forward.

Prioritizing delivery to customers over security creates real dangers for the business. Veracode has found that 63 percent of internally developed applications are out of compliance with the Open Web Application Security Project (OWASP)’s Top 10 standards when initially assessed for security. And, attackers increasingly target the application layer, with web application attacks now the most frequent pattern in confirmed breaches, according to the 2016 Verizon Data Breach Investigations Report.

Empowerment = Security

Regardless of where your team is in the DevOps journey, you’re likely aware that detecting and fixing quality issues as early in the software development life cycle (SDLC) as possible increases efficiency and reduces costs. According to the Puppet 2016 State of DevOps Report, “high-performing development teams spend 50 percet less time remediating security issues” when they address security throughout the SDLC, instead of “retrofitting security at the end.”

While you want to find and fix bugs early in the SDLC, early detection of coding flaws has the unintended consequence of distorting an application’s risk posture. Development is once again in the hot seat, despite trying to do the right thing and testing new versions of an application early in the life cycle.

There is a middle path that can allow development to deliver more secure code at DevOps speed, but it requires automating security into the SDLC and into a continuous integration or continuous deployment (CI/CD) pipeline. Integrating security into the pipeline ensures that security testing happens with every release, and avoids the problem of bolting on application security late in the process.

This method has the ability to scale easily as more applications are developed. The release engineer adds a step in the CI/CD build workflow for an application security scan from the master branch. The assessment can take place in parallel to the CI/CD workflow process and any security issues can be loaded automatically into the defect tracking system that development teams already are utilizing for functional testing. Security issues are prioritized and resourced just as any quality issue.

The best way to catch software defects quickly is to analyze code as close to the time that it was written as possible. Security assessment, such as functional testing, “follows the code” through the application life cycle. During the development phase, developers analyze code in the IDE and develop unit tests that will find issues relative to their individual code changes. At this phase, developers receive immediate feedback while coding a feature, allowing developers to remediate basic issues when they are least expensive to fix.

During the build and integration phases, when a development or feature branch is merged into the master branch, compilation and integration tests are executed automatically by the CI/CD workflow. Issues detected at this stage are visible to the larger development team. No developer wants to be the one who “breaks the build” or has a basic defect that should have been detected during development phase. The integration testing is critical because functional and security tests are able to detect issues resulting when data and control flows between components. Coverage of the application expands and developers still have the time to fix before code goes moves to the next phase.

Enter Infrastructure as Code

“Infrastructure as code” (IAC)—the concept of managing, provisioning and configuration of development, QA, pre-production and production environments in a repeatable automated methodology—provides consistency that previously was challenging when each system was provisioned and configured independently. Product teams using virtual machines (VMs) or containers are able to advantage of this model more easily.

Even for those product teams that cannot take advantage of IAC, teams can still automate the deployment and configuration of the application. This becomes particularly important during systems/pre-production testing, where finding issues takes longer to remediate and the complexity increases as the application integrates with other systems. At this point in the life cycle, system and pre-production tests are automated when possible, and QA engineers and user acceptance testers may run end-to-end tests. Running security assessments at this stage is just as important as functional tests. True, fixing issues at this stage will be more costly to fix than during the development phase. But by this point the developers have been incorporating quality throughout the process and the number of high-priority issues will be significantly reduced.

Empowering developers to find and fix quality issues earlier in the life cycle provides them with the knowledge and skill set to more efficiently fix defects where it is less expensive and disruptive to their coding.

About the Author / Janet Worthington

Janet Worthington is senior product manager at Veracode, working on solutions to help developers and development teams smoothly incorporate security into the application development life cycle. Janet joined Veracode in 2012 as senior program manager, delivering Veracode’s secure development solutions to Fortune 100 companies. Prior to joining Veracode, she led software quality assurance test teams at a number of startup technology companies. Janet has over 19 years of experience in software product development and services. Connect with her on LinkedIn and Twitter.

September 26, 2016
Fixing Flaws: Bridging InfoSec and DevOps

The Road to Creating More Secure Code and Interlocking two Traditionally Distinct Practices

As DevOps continues to expand across verticals, including the financial and government sectors, security has become paramount in the minds of CIOs and CTOs. As such, more organizations have begun to integrate security early in the development process. While security always has been a theoretical part of DevOps, the number of breaches making headlines recently and costing many IT professionals their jobs has taught us that now it is more important than ever for companies to build security into each and every methodology and practice. “Build it in from the start” is a fitting mantra for any developer today—and even more so for his or her boss.

Creating more secure code for products and platforms starts from day one in the planning stages, and some industries are doing it better than others. You must include security—not just in the end product and late development stages, but also throughout the life cycle. Organizations can do this by employing a defined methodology and unified tools that support that methodology, so developers make security not only a consideration for their end product, but something fundamentally baked into their build.

To achieve this harmony between Development and InfoSec, developers and Operations staff must be included in decisions about tools, standards and methodologies that the organization will follow. They need to understand what requirements are coming down the road so they can recognize the need to address those requirements in advance, rather than than being caught off-guard by problems or issues after the fact.

Build a DevOps Toolset with Dev, InfoSec Buy-in

It’s important to recognize that the door swings both ways; InfoSec folks can’t simply give developers a laundry list. Developers must be able to communicate their needs when it comes to security, and also must take an active role in the security of their product.

Part of the importance of this two-way street is recognizing the benefit of having developers involved in security decisions from the beginning. When Dev stakeholders are given the opportunity to participate in the purchase decisions of security tools at the outset of a project, they gain insight not only into the importance of incorporating that tool into their build as well as an understanding of what the capabilities of that tool are. After all, the most expensive part of application security is having to start from scratch because of poor initial planning.

When it comes to tools and security, good security is not necessarily what you buy but what you build. A good place to invest is at the DevOps tool level, where developers can build a process and methodology that allows them to create secure code throughout the process. This is a crucial step that limits point-in-time testing after the product is built—which can lead to expensive re-engineering.

Teach Teams: A Bug Fix is not a Security Risk

One way to keep costs down and priorities straight when addressing security challenges is to keep security issues and bugs separate from each other. Bugs are bugs and we all want them fixed, but a flaw in a piece of software is not necessarily always a security risk and does not necessitate an immediate fix (despite what the stakeholders for that feature might tell you). Finding flaws certainly should be immediate, but the process of fixing those flaws should involve prioritization.

This does mean, however, that evaluating flaws in a very timely manner is important, and one of the first questions you ask yourself when addressing potential flaws or bugs in your software product should be, “Does this pose a security risk?” If the answer is yes, you can quickly pinpoint the source of that risk and address it. The good news is that by doing this, you can greatly reduce the potential of your product having security risks you either a) didn’t know about or b) didn’t think were actually security issues. The challenge is that this is a constant and ongoing process. Be sure though, the benefits are well worth the time you’ll invest.

Recognize Fixing Flaws is a High Priority

It also can be difficult to balance the practice of fixing security flaws versus adding new features, particularly when developers are getting pressure from above to continue adding features and improving the end product.

Again, you need to look at risk. By weighing the benefit of features against the risk of flaws, you will be able to make smart decisions for prioritization. For just about every software product out there, security flaws should be addressed before new features.

It’s also worthwhile to consider the fact that bringing new features into a flawed environment is probably not a great idea. Not only does it mean you still have a fundamentally “broken” product, but that new feature may 1) not work as you expect or 2) increase the security risk further. If the second scenario is the case, now you not only have to fix the initial security flaw, but you also may have to reel that release back in—something you probably would rather avoid.

It’s also important to remember that good tracking, knowledge preservation and collaboration let you pinpoint issues, understand dependencies and determine the trade-offs faster.

Security is not an Option—It’s a Must

If you are looking for inspiration on how to better incorporate DevOps security best practices into your development process, look no further than government, financial and pharmaceutical industries. These industries face heavier regulations than just about anyone when it comes to security requirements, so they are continuously delivering secure software. Not only do they have to include security in their development process, they also must test that security and have defined educational requirements for their developers. In this end, all of this leads to some of the best and most sophisticated security practices in all of DevOps. If you want to gain good insight into how you can improve your security and see some of the latest advances in software development security trends, these are the industries you should pay attention to.

The surest way to provide a poor user experience and to compromise an organization’s success is to allow a security breach that could have been prevented with better foresight. That is why security best practices for DevOps (or rugged DevOps) are so important. By following the recommendations above and employing some of these tactics into your DevOps process, you can decrease risk for you and your company, and ultimately have more confidence in the success of your product.

About the Author / Ward Osborne

Ward Osborne serves as Information Security Officer at CollabNet and has more than 20 years of experience in Information Technology and Security Management. For the past 15 years he has focused on security integration and cloud security and has worked with dozens of companies of all sizes creating a culture of security and using security as an accelerator in business processes. Connect with him on LinkedIn and Twitter.

September 20, 2016
Top 5 DevOps Practices to Improve Security in Engineering
We’ve all been there … A new application or feature needs to be deployed yesterday and the last thing anyone wants to do is address security requirements. On the flip side, the very last thing anyone wants to address later is a security breach or a cost associated with non-compliance. Not only is it a massive headache but also it’s extremely expensive. According to the IBM X-Force Threat Intelligence Report 2016, the average cost of a data breach in 2015 was $154.20 per record ($363 per healthcare record) with the average total cost of a breach estimated at $3.79 million.

Not only is a breach expensive in terms of cost that can be easily quantified, but there are also costs that are harder to quantify such as the impact to branch image and customer loyalty. According to a new FireEye research report, 76 percent of respondents would likely take their business elsewhere due to negligent data-handling practices. In an incredibly competitive technology space, none of us can risk turning a blind eye to security if we want to attract customers with cool new features and then keep those customers with trust and reliability.

Security seems to be one of those topics that you either love or hate. I’m personally interested in it; however, I realize it’s not an interest shared by all. In the land of unicorns, we want all developers (infrastructure and application) to have more ownership in security, but tight schedules combined with the lack of expertise and reliable controls often can make that strategy unreliable. To make matters worse, a secure system and application isn’t something that is always glaringly visible to an end user or product owner. As a result, security may easily get deprioritized as something that “can be fixed later.” The “fix it later” strategy can be a dangerous decision, as many cybercriminals now are actively taking advantage of those that deploy quickly without adequate controls. How do you balance the customer’s desire to have new features delivered quickly with the fact that they need secure systems protecting their data against malicious threats?

Several common DevOps practices inherently lend themselves to providing a development and delivery pipeline that can improve your overall security posture. DevOps combined with SecOps includes practices that shift operational and management aspects of a system to the left to ensure we are able to reliably delivery and manage secure systems.

5 Security Practices Worth Considering

Below is a list of the top five DevOps practices and tooling that can help improve overall security when incorporated directly into your end-to-end continuous integration/continuous delivery (CI/CD) pipeline:
1. Collaboration
2. Security test automation
3. Configuration and patch management
4. Continuous monitoring
5. Identity management
If you iteratively build in security practices as you move infrastructure and application code through the deployment pipeline, it greatly increases your security posture as well as decreases the cost of future rework.

Collaboration and Understanding your Security Requirements

Many of us are required to follow a security policy. It may be in the form of a corporate security policy, a customer security policy and/or a set of compliance standards (ex. SOX, HIPAA, etc). Even if you are not mandated to use a specific policy or regulating standard, we all still want to ensure we follow best practices in securing our systems and applications. The key is to identify your sources of information for security expertise, collaborate early and understand your security requirements early so they can be incorporated into the overall solution.

Security Test Automation

Whether you’re building a brand new solution or upgrading an existing solution, there likely are several security considerations to incorporate. Due to the nature of quick and iterative agile development, tackling all security at once in a “big bang” approach likely will result in project delays. To ensure the project keeps moving, a layered approach often can be helpful to ensure you are continuously building additional security layers into your pipeline as you progress from development to a live product. An example of building gates in as you progress through your pipeline is shown below. Security test automation can ensure you have quality gates throughout your deployment pipeline giving immediate feedback to stakeholders on security posture and allowing for quick remediation early in the pipeline.

Configuration Management

In traditional development, servers/instances are provisioned and developers are able to work on the systems. Sometimes there is a “golden image” developers use to provision that can ensure that the provisioned servers/instances have a hardened operating system. However, as soon as any additional development and configuration activities happen on those servers, that server is no longer golden. To ensure servers are provisioned and managed using consistent, repeatable and reliable patterns, it’s critical to ensure you have a strategy for configuration management. Your strategy may include Chef for one situation, Salt for another situation, immutable infrastructure, or a combination of practices. The key is ensuring you can reliably ensure and manage consistent settings across your environments.

Patch Management

Similar to the concerns with configuration management, you need to ensure you have a method to quickly and reliably patch your systems. Missing patches is a common cause of exploited vulnerabilities including malware attacks. Being able to quickly delivery a patch across a large number of systems can drastically reduce your overall security exposures.

Continuous Monitoring

Ensuring you have monitoring in place across all environments with transparent feedback can alert you quickly of potential breaches or security issues. It’s important to identify your monitoring needs across the infrastructure and application, and then take advantage of some of the tooling that exists to quickly identify, isolate, shut down and remediate potential issues before they happen or before they become exploited. Part of your monitoring strategy also should include the ability to automatically collect and analyze logs. The analysis of running logs can help identify exposures quickly. The collection and analysis of security logs can identify issues that require remediation as well as provide automatic collection of compliance evidence. Compliance activities can become extremely expensive if they are not automated early.

Identity Management

DevOps practices help allow us to collaborate early with security experts, increase the level of security tests and automation to enforce quality gates for security and provide better mechanisms for ongoing security management and compliance activities. While painful to some, it has to be important to all if we don’t want to make the headlines.

We are all busy keeping up on everything that is emerging in technology and it’s difficult to keep up on all of the latest issues, so relying on reputable tools and reliable sources of information can be extremely beneficial. Some of my favorite resources in this area are The OWASP and SC Magazine. IBM X-Force is another great reliable resource to check out for the latest threat research and services. There are also a slew of tools out there to help with different areas of security in each of the practices covered in this blog. I’d love to hear about some of your favorites at @Shelbee_SE.

About the Author / Shelbee Smith-Eigenbrode

Shelbee Smith-Eigenbrode is a senior software engineer/IT architect at IBM and has been in IT for 19 years. She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.
September 12, 2016
Software Assurance Takes Center Stage at Developer Day
Cloud Security Alliance and SAFECode Develop Training for Improved Software Security Using Cloud and DevOps Practices

Software assurance is one of the most important and possibly one of the least understood areas of software development today. Software assurance is a comprehensive process that encompasses a set of design, coding and testing methods for ensuring that software functions as intended without introducing vulnerabilities, malicious code or defects that can bring harm to the end user. This approach is especially important in the cloud because increasingly the tools for developing applications are coming from cloud providers. The architecture for applications is changing rapidly and requires developers to understand the risks and vulnerabilities when developing applications in the cloud environment.

As we continue to see vulnerabilities within applications that lead to exploitation and theft of data, there exists a lack of acknowledgement in how to properly define and address these issues. With increased expectations on reducing time to market, development teams are pressured to work in sprint cycles using agile methodology thinking. New feature development is put first and developing secure code can become an afterthought.

While individual companies do implement effective methods for developing and delivering more secure and reliable software, except for a small number of organizations such as Software Assurance Forum for Excellence in Code (SAFECode) and the Cloud Security Alliance (CSA), there have been limited coordinated, industry-led efforts to build upon this positive work and promote best practices to advance software assurance more broadly, especially in cloud technology.

Inaugural Developer Day Planned for Sept. 12

The inaugural Developer Day event launched by the Cloud Security Alliance and SAFECode is a workshop developed to address these issues by educating software professionals on the challenges of improving software security using cloud and DevOps practices. A unique curriculum was developed by CSA and SAFECode to address the challenge of improved security using cloud and DevOps practices. The event is free but pre-registration is encouraged:

WHAT: SAFECode/CSA Developer Day

WHEN: Monday, Sept. 12; 1-6 p.m. PDT

WHERE: Adobe Systems Incorporated Corporate Headquarters
345 Park Avenue, San Jose, California
Park Room, East Tower

Event Fee: Free

Registration: https://www.eventbank.com/event/777/register/

Developers play a critical role in secure software assurance, and in today’s IT landscape, this role has never been more important. The application of effective software assurance methods is a proven way of enhancing and preserving trust and reliability of software.

A Practical Primer on Software Assurance

The half-day Developer Day event provides software developers with an important general primer on the core principles and applications of software assurance, and how to build in security utilizing cloud and DevOps practices. Attendees also will be provided with insight on state-of-the-art software assurance trends and learn how they can deepen their knowledge of software assurance. The event agenda includes three sessions:
- SAFECode: Driving Software Assurance among Software Professionals
  - Fundamental Practices for Software Assurance
- CSA: Cloud + Dev = Security Awesome
- Putting Theory into Practice: Software Assurance Case Studies
SAFECode and CSA created the Developer Day with two goals in mind. The first was to share recent developments and trends in the practice of software assurance across a number of different domains. The second was to demonstrate the top ways to combine development practices such as DevOps with cloud deployments to increase security without slowing things down.

Online Software Assurance Training Available

If you can’t make Developer Day, SAFECode and CSA also recently launched a jointly developed free, online, on-demand cloud security training program called, “Basic Practice s for Service Development of Cloud Applications.” The two-part training program teaches students about different cloud models as well as basic practices and aspects of secure development of cloud applications. It is part of a broader security engineering curriculum made available for free by SAFECode.

About the Author / John Yeoh

John Yeoh is the Senior Research Analyst for the Cloud Security Alliance (CSA) working within industry working groups, SDOs and strategic relationships in the development of cloud security standards, tools and solutions and strategy development. With over 15 years in research, John has authored reports on IT, cybersecurity, cloud and new technologies. His thought leadership has been presented in SC Magazine, USA today, Information Week and others, and he currently sits on numerous technology committees in government and industry. John’s graduate studies include Massachusetts Institute of Technology and University of Southern California with undergraduate work at Eastern Washington University and University of Washington. Connect with him on Twitter and LinkedIn.
September 9, 2016
It’s All About the Tools: Lifecycle Security and Testing

In the past, whenever a new application or a new version of an application was bought to market, users often were abused as beta testers for security and usability. This was largely because of a lack of opportunity to test a large codebase effectively and efficiently.

Similarly, the subsequent patches and new applications versions were rolled out with minimal testing, often fixing the existing bugs but introducing just as many new ones. Because users didn’t know there was an alternative, they accepted this situation grudgingly, and the consensus formed that there was no such thing as bug-free software.

Today’s users are much less tolerant of bugs, particularly when those bugs are security vulnerabilities in hosted applications. Nowadays, anyone offering an application online rarely has to wait long for hackers to examine the weaknesses, which, for suppliers, means the integrity of their own networks are at stake. Finding these security weaknesses in e-commerce applications or online booking systems, for example, is highly attractive to hackers because of opportunities for identity theft or to issue ransomware that may damage the company’s sustainability.

Hackers don’t just target the obvious bugs in applications. Distributed Denial of Service (DDoS) attacks increasingly are aimed at an application rather than the network infrastructure, often making the application unavailable to legitimate users.

Developers need to ensure they understand the importance of security and load testing over the application development life cycle. To deliver more secure products to market, it is essential to identify the aspects of development that can harness security faults and address these challenges with the time and financial support of C-suite and IT executives.

Lack of Time for Security Testing

Security defects must be avoided as much as possible. This requires intensive testing and the right tools. Time is precious, and time-to-market often is a critical success factor for new applications. For IT decision makers, it’s necessary to balance these security concerns and time pressures with an organization’s appetite for risk and its allocation of resources.

In addition, IT leaders and developers need to look at the effectiveness and agility of their security testing. Agile software development decreases the period between software releases from months to days or even hours. It is widely acknowledged that the classical iterative, develop-test-develop process for troubleshooting takes too long, so it often is overlooked. As a result, security defects often still find their way into software versions and must be eliminated later, which drive costs higher. For example, according to the National Institute of Standards and Technology (NIST), the cost per defect in the development stage is US$80, but quickly jumps to US$960 per defect in the testing stage and US$7,600 in production. NIST estimates that these costs amount to almost US$60 billion annually in the United States alone.

Developers are widely aware of the growing challenges with security testing. In a recent Ixia survey of 363 developers, a clear majority of respondents nominated security testing as the most critical component of the development cycle. In fact, 93 percent report they subject their applications to security testing during the development process early, and continuously. And yet, two-thirds of the respondents admitted to delivering products with bugs and/or security flaws. Whether this is because of a lack of time, appropriate tools or financial support, this can put application security and functionality and an organization’s network at risk. Subsequently, eliminating these defects with patches or updates is at least four times more expensive than addressing them during development.

Test Early, Often and Under Real Conditions

A range of comprehensive security testing solutions are emerging to integrate security testing more closely with the development cycle. These solutions give developers powerful and comprehensive test environments to monitor application behavior carefully in response to DDoS attacks, malicious traffic and automated attacks, which lets developers identify bugs or vulnerabilities at the encoding stage. These tools also generate realistic traffic for load and safety tests to simulate a wide range of protocol mixes and traffic patterns. In addition, these solutions include development tools such as integrated debuggers that import and replay recorded packet captures.

By using REST APIs and a rich command line interface, these integrated security testing solutions work with a range of continuous integration/continuous deployment (CI/CD) frameworks. These agile CI/CD frameworks streamline discovery and resolution of issues found in different phases of the application development life cycle.

These solutions also streamline communication and reporting within multifunction teams via a range of community features such as referrals, real-time feedback and task allocation. Using a completely virtualized solution also lets developers improve security testing across the application life cycle while minimizing any hardware or infrastructure investments. Plus, the agile CI/CD model helps disparate teams across the service provider—QA, production, development and vendor collaborate effectively and streamline discovery and resolution of issues found in different phases to accelerate the time to market.

The ability to increase the development team’s agility and speed while improving application security is making many IT decision makers sit up and take notice. With company boards requiring IT departments to respond more quickly and effectively to technology opportunities, IT leaders are seeing the benefits of this new way of working that combines the twin priorities of agility and security.

Developer teams should communicate clearly with IT executives to secure the required time, money and resources to ensure new applications and updates undergo rigorous and realistic tests before they are released to market to face the mercy of hackers. Using commercial tools and systems for security and load tests help to determine the behavior of applications under different stress loads. They also help developers deliver products to market in a more cost-effective, timely and agile manner.

About the Author / Phil Trainor

Phil Trainor is Head – Security Business, APAC at Ixia. Phil has worked in the network security industry for 14 years holding senior level engineering roles at California-based startups. He was recently a guest lecturer at the 2016 RSA Conference in Marina Bay Sands discussing ‘Advanced Persistent Threats’ and has also lectured at Blackhat, DefCon, ToorCon, and at many other prestigious security events. Connect with him on LinkedIn.

September 6, 2016
DEF CON: Where Have All the Black Hats Gone?

DEF CON is one of the most controversial conferences in the world. Only at that annual event have arrests been made, legal threats shut down presentations and zero-day attacks been anted in Texas Hold ’em games.

The Usual Suspects

This is a conference of people who grew up like me—people who, at 11 years old, were using IRC (internet chat relay) to share API (application programming interface) documents or download random material such as, “The Anarchist Cookbook.” We were influenced by movies such as, “The Matrix,” and “Hackers,” all the while thinking elite hacks were the cool thing to do. We spent lots of time playing Quake and other games. As we grew up, we may have gotten into trouble building projects using proggies or sharing things we weren’t supposed to share. Most of us grew up using computers to build software and make money. Some of us graduated from college and found great jobs for our skills.

You start with chat rooms on AOL and dive deeper into IRC. You may meet people playing peer-to-peer games such as Quake. Those people share information, and, before you know it, you’ve downloaded software over peer networks and you’re sharing cracks. This is your hidden world, and your friends are handles with no name, age or location.

Then one day you decide you’re going to meet all these handles in person at a central location that is easy to get to. You’re going to save up some really good cracks you haven’t shared yet for when you meet them. That, to me, was the adolescent rebellious start to DEF CON.

Now, as adults, we appreciate the novelty of slipping away into childhood by attending DEF CON to witness new hacks and meet childhood hacker friends. It’s like meeting a bunch of people at your house who haven’t seen each other in a long time or only knew each other through internet chat rooms. It’s a good time to connect; it’s great to feel that energy.

Going Down the Rabbit Hole

Hackers are just curious folks who are so bored with all the content they consume that they turn the internet into a playground. Like every playground, there are good guys and bad guys. Sometimes they’re forced to get along. Sometimes they fight. Sometimes they decide to attack a system just because the company that runs it laid off a loved one. Other times they are just playing a friendly game of King of the Hill. You can take it too far and get in trouble or get a wake-up call. Or, you may simply grow out of it. No matter the situation, the curiosity and love for the internet remains with you; that is why DEF CON is attractive.

DEF CON is white hats teaching black hats and black hats teaching white hats with a lot of gray in between. Everyone gets along and smiles as they watch “The Matrix” or “Hacker Jeopardy” together.

Distinguishing the Hackers from the Hacks

I was waiting in line. I always communicate with the people in line and ask them about the conference, current presentations and whether they have had any experience setting up XYZ or running up a large sheet of attacks using cloud networks. At this year’s event, most of the people I ran into looked like “hackers” but had no clue what I was talking about; they just uncomfortably laughed. It’s funny: They were going to presentations to see somebody talk about something highly technical, yet, they didn’t have a clue.

Lots of folks had badges, hung out and looked as though they were on vacation and decided to check out the conference. This group, I believe, came because the conference was located in a casino in Las Vegas. The whole Vegas thing is probably the top reason why DEF CON attracted larger crowds.

I noticed I found more competent folk at the Villages—different sections focusing on topics such as packet hacking, car hacking and social engineering. Villages had more unique, specific details on the concept of hacking in certain arenas. I found people were more in-tune and focused here. The Villages were away from the four main presentations rooms, which meant fewer tourist types. The Villages were where you found the passionate hackers.

White or black, it was a lot of gray. I didn’t see my friends who specialize in network protection for a living using hacker tools maliciously; rather, they were curious to know how the tools work. After Justin got his MitM (man-in-the-middle) attack working, he smiled and looked at me, “Is it this easy!?” Then, “How do we stop this? Is it really just making everything TLS? That can’t be the only way.” So we ran a few Google searches to poke around deeper. When moving around the conference, you saw guys sitting on the ground running these attacks; they were just phishing to add to the wall of sheep.

Was the guy who got paid to snoop at the Democratic National Convention convention with MitM attacks there? He might or might not have been. He might have been pioneering these attacks and learning from presenters, or he might have been so beyond what is shared at DEF CON that it was a mere novelty to attend. Even with DEF CON making it really easy to go undetected by using cash transactions, it’s still 2016 and surveillance cameras were everywhere—especially in casinos. If you’re looking to keep a low profile, DEF CON is the last place you’d want to be.

So, I’m going to go out on a limb and say that the white hats and some grays were present with maybe a Sith Lord lurking in disguise. The true black hats were most likely reporting in remotely to their Sith while they observed petty hacks and recruited from a safe distance. Or maybe, just maybe, they were in board shorts acting like a clueless tourist.

About the Author / Randy Apuzzo

Randy Apuzzo is founder and CEO of Zesty.io, the SaaS CMS Company. At age 12, Randy was hacking corporate sites and crashing systems for fun. As an adult, he applies his computer science and branding background as an industry visionary, architecting scalable solutions that help companies accelerate and scale their global digital content strategies. He is revered for empowering businesses with technology that grants agility, cost savings, security and increased market share. To connect with Randy, please visit https://www.zesty.io, Facebook/GoZesty, LinkedIn/Zesty-io, @RandyApuzzo and @Zestyio.

September 2, 2016
Private Practice: Encryption Exposed

In September 2014, Apple made encryption a default with the introduction of the iPhone 6. Then, in February 2016, a Los Angeles judge issued an order to force Apple to help break into the encrypted iPhone belonging to a terrorist involved in a mass shooting.

Apple had used some of the strongest encryption technologies and practices to protect its users and their data. The encryption technology did not discriminate between lawful and unlawful users. While there were many sides to this issue, it surfaced many important debates on security, privacy and civil rights.

Peekaboo

For developers wanting to add cryptographic libraries to their applications, a number of open-source components are available to them. Of course, anyone seeking to add encryption to an application has an important requirement for the privacy and security it provides.

One of the more popular choices for encryption is known as the Legion of Bouncy Castle Java Cryptography library. According to the “2016 State of the Software Supply Chain” report, records reveal that 17.4 million Bouncy Castle components across all versions were downloaded last year. Of these, 5.8 million (33 percent) were known vulnerable versions of Bouncy Castle.

It’s a sobering fact, but it’s true. Last year alone, organizations downloaded vulnerable versions of the Bouncy Castle cryptography library 5.8 million times. The defective components downloads occurred across 93,253 unique IP addresses from 13,824 organizations in 197 countries.

Think Different

Think about it. The Bouncy Castle project is developed by experts in cryptography. Occasionally, their crypto library is discovered to have a flaw and the project owners rapidly fix and release a new version. If you use the latest versions without known vulnerabilities, your application, your users and your data are protected. If you use the versions that include known vulnerabilities, you have electively declined those protections.

Two of the critical principles of using open-source components are to use the highest quality components and to select them from the best suppliers. In this case, the Bouncy Castle project does an excellent job of releasing new and improved versions. While flawed versions are still available, those seeking to protect applications, users and data need to use the highest quality versions.

Which Version Are You Using?

Determining which versions of Bouncy Castle or any other open-source component you are using is simple. A number of free and paid services are available to help you analyze your application and report a full list of the components, including dependencies, that are used.

Some of the free services require you to upload your application for analysis while other services are performed on-premises. One example of a free on-premises tool used to create a software Bill of Materials is the Application Health Check app from Sonatype. Another example is the OWASP Dependency Check app. Precision of these tools may vary, but regardless of the tool you use, you should use one.

More insights on the quality, security, and integrity of open source components used to build modern applications can be found in the “2016 State of the Software Supply Chain” report.

September 1, 2016