devopsy.kinsta.cloud

Tag: security

DevOps and the Identity Conundrum

“Who am I?” It is perhaps the most basic question of consciousness. The answer could be subdivided by aspects of my life story … my career, my family, my beliefs, my education … the list could continue. But since I am unique, the challenge in this digital age is for me to somehow remain unique, and whatever descriptions are used to catalog who I am, I must remain at the center of them all. If my identity is stolen, how does anyone know, that I am who I say I am?

This question is fundamental to every interaction I have with the digital world. And unfortunately, every system I interact with looks for me to redefine who I am, over and over again for each of them. I create a Facebook profile, a Twitter profile, a LinkedIn profile … and the list goes on again. But yet another weakness of our digital age is that there is no cross-reference between these systems to ensure I am who I say I am. This phenomenon remains true within DevOps tooling as well.

The Career Identity Conundrum

Let’s focus on only one aspect of who I am, my career. Who my current employer is dictates what electronic business systems and networks I should have access to. Switching jobs to another employer changes—or should change—the access I have. But getting more specific, what my role is at my current employer should also have an impact on what tools I have access to, and what I can do within them. And as my role changes, my abilities within a tool should change, as well. If I move from practitioner, to manager, to director, my abilities within a given tool should probably diminish, holding practitioners accountable for actions rather than superseding their responsibility by doing things myself.

Then there is the area of focus I work on. Business segmentation differentiates my work from product or service “A” in contrast with product or service “B.” My role might be an application programmer, or database administrator, but then “who” I focus on within a company is yet another level of differentiation. The business may prefer that teams of people focused on product “A” are restricted from making substantive changes on product “B.” So two different database administrators need two different levels of access within the same tooling, segregated by line of business or product line to accomplish it.

The Career Consistency Conundrum

The problem with my corporate identity in the digital age is that it is fluid, like life. In the course of my career I will change employers at one time or another. But beyond this, I will change roles, and/or areas of focus within the same employer over time. I may be assigned to work a “special project” in addition to my normal duties during my time at a given employer. And where DevOps relies upon several types of tooling to facilitate the continuum, this fluidity in my career makes it difficult to keep up with, and can drive administrative costs quite high.

For example, if I am an application programmer (normally), I will then have certain abilities within the build, deploy and release tools—likely high ability in build, moderate in deploy and low in release. If I am temporarily assigned as a release manager for a different product/service (in addition to my normal duties), it should radically alter my abilities within the DevOps tools, at least for a short time. But when I return to normal duties, the only mechanism that gets my abilities reset to what they should be is a strong process control system. The tools do nothing to facilitate this (no reminders, no examination of HR systems for roles, no look at each other to see what I am supposed to be).

An Identity Architecture

It occurs to me that the constants in resolving these kinds of problems are time and who I am. If I could hold an identification construct that identifies myself in career terms—which employer, which role, etc. and for how long—that identity construct could be employed into every system that accepted it. In effect, it would be the ultimate abstraction of user management, transferring the burden from companies and HR departments to the individuals who know, and need to know, the end user. While companies would still need to interact with my personal identity construct for verification, assent and record keeping, having all electronic systems accept my ID construct takes all of the work out of programming those interfaces, makes permissions and roles common, and keeps up with life’s fluidity.

In addition, who I am becomes the same in every system that accepts this construct. I cannot define myself as a release manager in one tool and a test manager in another and an application programmer in yet another to give myself god-like abilities in the DevOps tooling at my company. Each tool would examine the same identity construct I hold and receive from it, my normal duties, roles, permissions, etc. I would have a consistent profile across corporate tooling that would reflect my latest roles and use dates (beginning and end) to validate me against their own records.

An Identity Lockbox

The trick is, how do I keep this identity construct from being stolen? I believe this is where biometrics begins to play a key role. Fingerprint technology is commonplace now, even in cell phones, which are usually chained to us like an additional finger or toe. We rarely go anywhere without them. And when carrying them, we use features such as Touch ID to replace the manual keying-in of passwords. If my identity construct was paired between information likely I alone would have and biometrics tuned only to me (retinal scans, fingerprints, etc.), the pairing could unlock the construct for either use or revision.

Stealing the construct does little good, as without the pairing biometrics, it could not be used or revised. The applications for an identity construct like this are limitless—everything from securing the right to vote, work and collect social security to validating credit card purchases and opening up new social media accounts. If Facebook employed (or accepted) this kind of construct, it would be more difficult to create spoof accounts of me, as the unbeatable pairing could decipher who really owns a photo, or document, etc. And looking forward, a standardized identity construct such as this could interact with the emerging world of IoT (internet of Things), where devices could know a lot about me, and know it was truly me.

Impacts to the Bottom Line

I am not suggesting some wild end-of-the-world scenario where computers control our every move. We already have that in some form or another (see banks – ha ha). But I am suggesting that in the interest of reclaiming digital privacy we should be moving the ownership of identity constructs back to the people who own them: us. We should each own our own singular construct, keep it up to date and as filled out or complete as we want to, sharing only what we want to. The chief benefit of this would be an increased difficulty in stealing them from us. We can all skip the 666 tattoos, and instead try to reclaim a moniker of privacy by holding our own digital identities ourselves. Using them like a master key that will open systems we “should” have access to and abilities we “need” to have to perform the work assigned to us.

The upside to corporations is increased security that requires less on their part to maintain. A single set of records with start and end dates validates IDs used or attempting access. The upside to the software industry as a whole is a common interface for logging into an application with discreet identification. It removes the doubt about “borrowing” an ID if unlocking access requires a biometric pair as well. It would allow every application to abstract user management and make it common. Roles would be abstracted. Permissions could remain unique to each application based on their interpretation of the role.

Moving to a self-maintained identity construct could be taken further for benefits in other areas of our lives. While we have discussed some of how the career portions of our identity might be subdivided and cataloged, imagine for a moment the benefits of having our heath characteristics attached to the same kind of identity construct. Family records, memberships and associations … pick your classification of how a person is described for who they are. Having a way to retain ownership of those things in the digital age is key to keeping our unique position in the world unique. Losing control of those things becomes catastrophic. Where DevOps benefits from a construct such as this is but the tip of an iceberg compared to the benefits society reaps—or at least, our digital society could reap if we pursued it.

To continue the conversation, feel free to contact me.

— Kristian Nelson

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
Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 2

As we covered in part one, DevOps’ best asset and biggest risk factor may be one and the same: swift and precious change. In part two, we continue our discussion of the challenges and solutions with Deena Coffman, managing director of BDO Consulting’s Technology Advisory Services practice.

David Geer: What specific tools and technologies can help DevOps teams to address change management in these ways?

Coffman: There are a variety of tools and technologies to address some of the inefficiencies in change management, allowing DevOps teams to automate most of the process. For example, teams can leverage change management software to build pre-authorization processes and workflows to speed up change management approvals. On the security side, infrastructure monitoring tools will alert an organization when a discrepancy is discovered on the network, providing application visibility to the users and monitoring for unauthorized changes. DevOps teams should also consider using a collaboration platform like Slack to improve communication via virtual meeting places.

Geer: What will these tools accomplish and how should teams be using them?

Coffman: These tools are only useful if used properly. Deployments that require change management approval can go through the automated workflows. If a change requires approval, developers can use Slack or any other collaboration platform to contact the required party and explain the reasoning behind the modification. DevOps teams must also take the time to identify and automate as many “standard” changes as possible to reduce the reliance on change control meetings to speed up their deployments.

Additionally, DevOps teams need to consider using an infrastructure monitoring tool to ensure all changes to the production environment are known and authorized. If a change finds its way to production without getting the appropriate authorization, the monitoring tools can detect it and report it to the team so they can rectify the issue.

Geer: What kinds of things do DevOps teams need to do to address security to the satisfaction of the business?

Coffman: The development team and security do not need to be at odds. By working in unison, both sides can reach their objectives.

The InfoSec team would help the development team by making efforts to reduce the latency of security projects. The development team would help not only the InfoSec team—but potentially the entire organization—by preventing an expensive and embarrassing security incident by diligently supporting tools that automate security checks.

Additionally, the build process needs to run unit testing, integration testing, functional testing, regression testing and information security testing before the code reaches QA. Security testing is often insufficient or not performed at all. DevOps teams need to understand that security testing performs an important function of catching issues early so as to avoid expensive, embarrassing issues downstream.

Geer: What specific tools and technologies can help DevOps teams to address security in these ways?

Coffman: Several tools are available to help DevOps teams address security in many different capacities, including setting up continuous integration/continuous delivery processes, automating server configuration, automating UI testing and functional security tests, testing the security requirements of applications and automating the vulnerability scan of applications and infrastructure.

Geer: What will these tools accomplish and how should teams be using them?

Coffman: DevOps teams should integrate these tools as part of their continuous delivery process. As soon as a developer checks his code in, the continuous delivery system should run the functional security tests, non-functional security tests and the security scan to ensure that the developer did not introduce a security vulnerability to the application and the infrastructure. These tools are only as powerful as the test scenarios they run. Therefore, teams should write exhaustive test cases to ensure the security of the application.

Geer: How can teams do all these things and still maintain all the benefits and expectations that people have of DevOps itself?

Coffman: By deliberately working toward improved collaboration and communication, teams can take advantage of the integration and efficiency benefits of a DevOps structure without sacrificing security or quality. Technical knowledge is important, without a doubt. To be exceptional, though, teams need equally strong teamwork and communication skills to actively support all important functions in the organization.

— David Geer

September 16, 2016
The devopsy.kinsta.cloud Containerization and Microservices Survival Guide

Containerization and microservices seemed to have leaped out of nowhere and smack into the center of the enterprise IT scene. But neither leaped from nowhere. Both containerization and microservices have been part of the fabric of enterprise tech for some time—within Linux for containers and service-oriented architecture for microservices.

Largely, thanks to containerization, both now are moving quickly to become central components of enterprise tech. Containers in recent years—and especially in recent months—have moved from tools used in development environments to production. And the ability to manage containers as discrete services is enabling enterprises to be able to respond quickly and be agile to technology demands.

According to a recent survey from app performance vendor NGINX, of roughly 1,800 IT professionals, while container and microservices software adoption is limited it’s use is accelerating. The survey found that only 20 percent of respondents said they are using containers in production, while about one-third are doing the same for microservices.

That survey, not surprisingly, indicated that microservices and container use will continue to accelerate, as roughly two-thirds of respondents said that they are currently evaluating containers and 70 percent microservices.

Microservices are workloads that perform a single task and they are not dependent on the infrastructure or other applications for their ability to complete their designated task or “service.” Microservices are very effective at providing enterprises the ability to rapidly build software that solves business problems. They also make it possible for development teams to scale their efforts and build a more resilient architecture.

With all of that in mind, and considering the nature of the inflection point most enterprises find themselves in now, we’ve assembled this microservices and containerization survival guide. The guide consists of some of the most important storage on microservices and container management that we’ve ran in the past year.

DevOps Teams: Containers Will Help You Become Future Ready

According to The State of Containers 2015 Docker Adoption Survey, more than 70 percent of respondents are either using Docker or evaluating for future use. Given the overwhelming popularity of containers, this post provides three trends that DevOps teams must be prepared for.

7 Web Interfaces for Container Management and Orchestration

Managing containers used to be a command-line affair. But a rich and growing ecosystem of web-based interfaces for containers has now emerged. This post provides an overview of the different web UIs available for container management and orchestration.

‘Containers-as-a-Service’ Is a Hot Trend

Containers are still sort of the new kid on the IT block, but already containers-as-a-service is emerging as a thing. Here’s what you need to know.

A Closer Look at Container Monitoring

Enterprises have to ensure that all of their microservices perform well and provide their services as designed. Beyond that, how much do they really need to know about what’s going on inside their containers? The answer to this question varies. In this post Gerald Haydtner provides an overview for container-monitoring options.

Containers: Not One to Rule Them All

When it comes to the container platform ecosystem, not all container platforms are created equal. This post will help you sort through the options.

Building Microservices: A Few Considerations

An experienced practitioner details the top five design considerations when building microservices.

5 Docker Best Practices You Should Follow

Support for Docker has been integrated into many products and platforms and a lot of organizations are either already using Docker containers or trying to understand how to do so themselves. Our Tony Bradley provides the Docker best practices one needs to know to succeed.

How to Choose a Cloud Platform for Containers

Containerization has broadened from one or two vendors to a broader, more container-agnostic world and a drive to better scalability, redundancy, interoperability and security. Amazon, Google and Microsoft each have their own unique approach to addressing these cloud container concerns as they battle each other for supremacy. Here’s a look at how to evaluate each.

Container Security: Why Bother?

Are containers secure? Probably not. But knowing each approach’s strengths and risks—and available options—could help ease adoption.

Container Security Challenges: Are Container Scanners Enough?

How secure are containers? Not very, according to open source company Red Hat, which has published a blog post blasting the container ecosystem for lacking good security processes. Here’s a synopsis of what Red Hat has to say about container security, and some additional perspective.

For Container Security, Automation Is Key

Regardless of the IT infrastructure element in question, if it connects to a network—even through proxies or human intermediaries—eventually someone will find a security flaw and exploit it. Compatibility issues with new applications or infrastructure elements will emerge. Because of these reasons, all IT infrastructure elements need to be managed, without exception.

Containers and Security Q&A: Putting a Lid on Risk

How do containers affect security? And how can IT teams do everything they need to do in order to ensure the containers in use are as secure as they reasonably can be?

— George V. Hulme

September 15, 2016
Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 1

DevOps’s best asset is swift and valuable change, which also may be its biggest risk factor. DevOps certainly challenges change management and security. We recently discussed these challenges and the solutions with Deena Coffman, managing director at BDO Consulting’s Technology Advisory Services practice. Here is part one of that exchange.

David Geer: What kinds of challenges does DevOps create for change management? Can you illustrate with an example?

Coffman: By combining the sysadmin and developer functions, DevOps can lend to “shortcutting” the change management process in the interest of expediency. It may also undercut the value of having a critical eye from both a distinct system administrator and a distinct development reviewer. DevOps is designed to move quickly, and while the pace of change is accelerating, speed is often an ingredient for a security incident. Much like having the same individual who approves invoices also issue a check, DevOps makes for a faster, but not always secure, process.

When the system of checks and balances can be purposefully circumvented, that privilege tends to be invoked more often than necessary. As a result, developers may bypass change management altogether far too frequently. The collaborative benefits from DevOps integrating typically siloed functions such as QA, software development, security and information technology operations are important, so long as they aren’t offset by compromises in quality and security that result from the reduction in the review and approval process.

The expedient nature of DevOps can also lead to error, given the absence of human experience involved in the evaluation process. Before DevOps, if a developer needed to change a setting on the web server, they would submit a change request and wait for approval. Under a DevOps structure, though, the developer simply scripts the change and commits it to the repository—automatically kicking off the build process. The process runs unit testing, integration testing, functional testing and regression testing against the new code, and then pushes the new code to the staging environment and finally, to production.

Geer: What kinds of challenges does DevOps create for security? Can you illustrate with an anecdote?

Coffman: The biggest security challenge in a DevOps environment is that speed becomes paramount, which reduces critical evaluation on security risks. Developers incentivized to quickly deploy new capabilities are naturally pushed toward productivity and efficiency, which often run counter to security. DevOps can skew that balance so that security is only lightly or sometimes insufficiently considered. Automated testing will test for known exposures, but a trained, experienced human may be able to anticipate a risk before it materializes.

Geer: How can flaws in change management in DevOps approaches lead to security issues?

Coffman: Flaws or inefficiencies in the change management process reinforce the views of those who are prone to bypassing what they perceive as tedious process requirements. If a change management process is too burdensome or seen as lacking value, people will avoid it at any opportunity—not just when an exception permits a bypass. Since technology professionals tend to have a bias against waste and inefficiency, introducing a process requirement that consumes time and effort without returning value has a high probability of triggering a wholesale negative reaction.

Geer: What kinds of things do DevOps shops and teams need to be doing to address change management so that they continue to meet the expectations of the business?

Coffman: When it comes to ensuring that change management meets business expectations, it really comes down to several key ingredients: flexibility, speed, efficiency and risk management.

DevOps teams should design and manage the change management system to be efficient, responsive, and flexible enough to accommodate cursory reviews for low risk scenarios and careful, in-depth reviews for other changes. Leadership needs to also set a tone of support for the change control process so it is not dismissed or marginalized. Additionally, engaging outside expertise and/or including additional quality and security measures for higher risk projects are recommended.

A risk review that identifies projects with security and privacy risk and distinguishing types of changes supports the automation decisions and builds a DevOps program that balances its benefits with risk management.

Stay tuned for part two.

September 13, 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
GRC: A Key Ingredient in DevOps’ Secret Sauce

By now, surely everyone has seen cooking competition shows such as “Hell’s Kitchen” and “Top Chef,” in which people compete to create and serve the best dishes as quickly as possible. These hit TV programs are like the DevOps world, which also consists of people creating and releasing the best software as fast as they can with whatever they are given. In both instances, the best use of random ingredients brings rewards and failure brings disappointment.

DevOps is becoming evermore common as companies in all industries work to unify their developers and other IT staff while automating as much of the process as possible, creating nimble, fast-moving teams. Think of it in the same way professional kitchens have cooks dedicated to specific stations, such as vegetables or fish, and are able to react swiftly to whatever orders are placed. By redesigning their in-house teams in this fashion, organizations can add speed, agility and resilience to critical functions.

But, often what’s forgotten in the high-pressure, rush-rush-rush world is the critical importance of security and regulations. Governance, risk management and compliance (GRC) always must form the base decisions; otherwise; the final products will either not be able to be used or, worse, be dangerous to the company, its customers and its shareholders. It’s really no different than cooks having to abide by health code regulations or risk sickening and possibly even killing their diners. Don’t think GRC is that serious? It wasn’t long ago that Dwolla was fined $100,000 by the Consumer Fraud Protection Bureau (CFPB) for lying to customers about data risks. That was the CFPB’s first fine and you can bet more are sure to follow.

Of course, a key difference is that in the business world, regulations and compliance standards constantly are being created or changed. That makes DevOps even more challenging, but that challenge cannot mean ignoring GRC. In fact, GRC should be seen as a key DevOps enabler, not an obstacle. An organization’s legal and compliance team can take advantage of highly agile, forward-moving DevOps teams to design and implement changes that satisfy risk and control points (resulting in successful audits and avoiding fines) while, at the same time, staying abreast or even beating the competition.

The key here is to ground DevOps in GRC requirements so they become second nature and security measures are incorporated effectively into all DevOps processes, even automated ones. It’s crucial these measures are seen as integral to the processes and not simply layered on top as an afterthought, just as you wouldn’t try to get raw chicken juice off of lettuce after you’ve made a salad.

Tactically speaking, how is this accomplished? DevOps teams need awareness and training. They need to learn the rules and laws specifically governing their particular industry, and how to implement them. And, companies need to have internal audits and other review policies in place to ensure GRC is enforced.

For all of this to happen, however, a very important role must orchestrate it: management. Just as every kitchen depends upon a head chef to ensure not only that each station is obeying health codes (i.e. the law) but also that overall the meal is being prepared and delivered properly, company management must assume its authoritative role in setting up and defining the organization’s internal communication. This means breaking down silos and coordinating a regular flow of information from Compliance to DevOps team and back again.

If this is done properly, DevOps can enable an innovational Nirvana, with companies boosting speed while maintaining security, creating the perfect consumer experience.

About the Author / Robert Hawk

Robert Hawk serves as Information Security Expert at xMatters, Inc. He has extensive experience in information systems security, computer security, cyber security, information assurance and governance, risk, and compliance (GRC) management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on LinkedIn.

September 8, 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