devopsy.kinsta.cloud

Tag: security

  • Q&A: Quali’s Wrabetz on Security Testing

    Q&A: Quali’s Wrabetz on Security Testing

    DevOps is the perfect storm of automated testing and development that should make secure software commonplace. Yet, there are hurdles to testing for security. devopsy.kinsta.cloud asked Joan Wrabetz, CTO of Quali, about security, DevOps and her laundry list of those testing challenges.

    David Geer: Isn’t secure software important to DevOps?

    Wrabetz: DevOps is a practice of continuously deploying applications into production clouds. In order to automate the deployment of applications into production, it would seem essential for security testing to be a part of that automated process. In fact, when talking with one financial services firm, they said that they don’t deploy continuously into production because they are concerned that to do so would break the law. They are required by law to ensure that applications comply with their regulatory and privacy requirements before they are deployed into production. The only way to do that is to perform security testing. Thus, in order to achieve continuous deployment, they would have to integrate security testing into their DevOps flow.

    Geer: So, why isn’t security testing a core part of DevOps already?

    Wrabetz: The reasons are both technical and organizational. Organizationally, security testing is usually handled separately from development or product release-oriented testing, often by a completely separate group. As a result, it is not necessarily associated with the application release process.

    The technical reasons are related. Historically, security testing has involved reproducing the production infrastructure and network configuration as accurately as possible so that security vulnerabilities can be identified. Often, development and test teams working on DevOps do not invest in creating accurate reproductions of production infrastructure for their normal development and testing. So, they are not prepared to perform security testing as part of their normal DevOps flow.

    Security testing at many financial services firms exemplifies both of these issues. These firms typically outsource their security testing to one of a number of service firms who perform that testing on their own networks or in the cloud. The outsourcing of the security testing process is a big inhibitor to incorporating security testing into a continuous and automated DevOps process. In addition, when we asked these financial services firms how well their outsourced security testing represents their real production information technology infrastructure, they really have no idea. Clearly, any testing that does not match the production environment is not helping to reduce the security risk that the organization faces.

    Geer: What kinds of security testing do you feel is most relevant to DevOps?

    Wrabetz: The type of security testing that is most relevant to the DevOps flow is application compliance testing. For this type of testing, new applications are inserted into a network that emulates the information technology production network as accurately as possible. Testing with load, traffic and disruptive events is performed to determine whether the new application or upgrade might open up a vulnerability in the production environment. That includes privacy and data protection regulations, security requirements and any other business compliance standards that the organization is subject to. This testing is performed before pushing any new upgrade or application into production to ensure that compliance requirements will be maintained.

    Geer: What are some common problems with security testing as part of DevOps?

    Wrabetz: There are some common problems that make this type of testing uniquely difficult as part of a DevOps process, and in many cases, much harder to perform than other hardware and software testing. For example:

    • The tests must run in a configuration that exactly matches the current production configurations.
    • Security tests are systemwide tests, not tests of a single piece of hardware or software.
    • The tests must run with realistic traffic that simulates typical production traffic.
    • Security testing must allow automation of setup, configuration and testing processes in order for it to be incorporated into a DevOps flow.
    • Networks are large-scale and difficult to reproduce in a test.

    Security Testing Critical

    DevOps is in its infancy, but it won’t be forever. Now is the perfect time to surmount these obstacles, test for security and feed the results back into coding for security early and often.

  • Best Practices for Cloud Deployment

    Best Practices for Cloud Deployment

    When it comes to deploying apps in the cloud, the conventional wisdom is that DevOps is not required if you’re a small or midsized company. The cloud is designed to enable virtually anyone to set up the infrastructure they need, quickly and easily, without a lot of experience in the intricacies of managing data center operations or hardware. But then, by the time the company realizes it needs DevOps, it’s almost too late—the cloud infrastructure has become complex, costs have exceeded expectations and precious time is being wasted.

    To ensure you’re able to optimize cloud, or hybrid cloud, deployments—and avoid many of the problems that other companies have experienced—there are a number of best practices you must employ within your company.

    Best Practice No. 1: Realize You Need DevOps from the Start

    When you manage your own hardware, you know exactly what the deployment costs are and what resources are available, and have a clear understanding of how they are interrelated. The abstraction of the cloud makes the initial setup a snap. But typically there is no formal structure involved: Individual developers can initiate new instances whenever they need them, without considering the bigger picture of the resources already in use, how they’re used or what is being planned by the organization.

    Spinning up unnecessary cloud resources not only costs a company more in the long run, it also leads to a cloud sprawl that requires time-consuming, manual processes to maintain. Think about the challenges your company would face if it had thousands of machines created by different processes but you didn’t know who created them, what they were being used for or  even if they were still needed.

    By employing DevOps from the start, you will be able to balance the needs of developers with the availability of resources in the cloud to ensure expenses do not run out of control and you understand exactly how the cloud infrastructure is being used now and into the future.

    Best Practice No. 2: Have a Process and Purpose

    As you create your cloud infrastructure, you need to have a clearly defined purpose, as well as a process in place for deployment and ongoing management. You will need to keep track of what resources are being used and their designated purposes. Some cloud vendors, such as AWS, offer tagging capabilities that help you keep track of what services each machine was created for and whether they are being used for production, backup, load balancing or testing.

    Regardless of whether you use tagging capabilities or maintain a separate database of cloud resources, knowing what you have purchased and how it’s being used will provide needed visibility, ease of management and greater control of costs.

    Best Practice No. 3: Leverage Automation

    Automation is important—both in the cloud and on premises—to streamline routine practices, make sure they’re applied consistently and eliminate potential errors that are common with manual processes.

    When deploying on multiple clouds or in a hybrid environment, it is important to understand that tags used for one cloud provider won’t work on another. The process is typically broken into three steps: inventory creation, system preparation and automatic deployment. Many cloud systems allow you to create a dynamic inventory directly from the servers, eliminating the need to create or maintain it manually. However, deployment over multiple clouds require an abstraction of this inventory; it is common to create a static inventory in a unified format from the various dynamic inventories.

    Best Practice No. 4: Design the Network with Security in Mind

    Poorly designed networks are almost impossible to secure. Problems often arise when companies allow their networks to grow organically rather than being planned out in advance. A number of companies have employed the best practice of segregating the services network and the management network. The services network includes all the components required to provide services to your customers and users, while the management network is comprised of what you need internally to manage the network. Separating these networks provides greater assurance that unauthorized users cannot gain access to your systems via the Internet.

    Another part of security is key management. Depending on the cloud provider, keys can be widely available or have a root password that is open to the world. In fact, many hackers routinely scan Github for keys developers accidentally check in. With having to manage so many keys, you may struggle to ensure that they’re not exposed. DevOps plays an important role in keeping the keys locked away, then providing them to a select group of individuals who can use them only in production.

    Best Practice No. 5: Be Strategic About Monitoring

    When you’re deploying hardware on-premises, it’s a common practice to define in advance what to monitor. But monitoring in the cloud is quite different, with basic defaults that produce vast quantities of data—much of which may not be relevant to your organization.

    Taking a cue from how you handle monitoring on-prem, you’ll want to design cloud monitoring to fit your company’s unique needs and filter out the information that isn’t pertinent to your network or operations.

    Best Practices Go a Long Way

    Keeping in mind these best practices and employing a DevOps model from the start will enable your company to get the most benefits from its cloud deployment regardless of its size, and avoid the costly and time-consuming challenges that arise without proper advanced planning and a strong focus on network design and processes.

    About the Author/Roger Fulton

    roger-headshot

    Roger Fulton is Iron.io’s director of Infrastructure and Operations. His background includes broad experience in software architecture and operational planning. He manages international teams to deliver highly available products for end users and highly performing in-house infrastructure. Prior to joining Iron.io, Roger served as head of application and infrastructure engineering at Kaybus. He has also held technical leadership roles at JRV Consulting Group, Cybrata, Invisible IT and Clarus Systems. Roger holds a Masters from the Queens University of Belfast, having graduated with highest honors.

     

  • Understand Why You’re Doing DevOps

    Understand Why You’re Doing DevOps

    DevOps has been all the rage for a few years now. It has quickly matured from a fringe concept to a mainstream imperative, and organizations that haven’t already embraced DevOps are scrambling to understand and implement it to keep up with rivals and remain competitive. Despite its benefits, though, DevOps may not be for everyone. Before diving into the DevOps deep end, you first should consider what your objectives are.

    To frame the issue more precisely, it’s not that organizations necessarily should avoid DevOps altogether. It’s just important to go into it with your eyes wide open and to understand why some DevOps projects fail. According to Andrew Storms, VP of Security Services at New Context, it’s always for one of four reasons: cultural roadblocks, failure to identify and take action on mistakes as you go, failure to learn from past mistakes and most importantly, failure to include security—either early on or at all.

    Let’s break down those four hurdles.

    Face Cultural Roadblocks

    DevOps is different things to different organizations, or even to different teams within an organization. There are many definitions of what DevOps is or is not. There is a fairly unanimous consensus, though, that DevOps is first and foremost a function of culture.

    Cultural roadblocks, Storms said, are by far the most common reason he sees DevOps fail. “It’s rarely a technical tools problem; usually there’s a disconnect between the DevOps team and executives or other parts of the organization. A concerted effort must be made to get everyone in the organization on the same page. Everyone is fighting for the same thing, but too often, they don’t realize it.”

    Fix Mistakes

    One of the outcomes of the DevOps culture shift is a fundamental change in corporate bureaucracy and the rigid processes that segregate teams and impede progress. DevOps enables organizations to work more seamlessly and produce results more quickly. It also allows issues and mistakes to be identified and resolved on the fly. “Smaller incremental changes are always easier to handle than a large monster of a release, which can include hundreds of changes,” explained Storms. “For example, teams should look for the single change in a monthly release that resulted in an unexpected security hole, instead of thinking they’ll tackle all changes with a huge release down the road.”

    Learn from the Past

    One of the most important things for business in general to help them understand is learning from past mistakes. With DevOps, it’s crucial. Organizations often only conduct investigations and postmortem analyses in the event of an issue or catastrophic failure. In that situation, the teams and individuals involved are immediately on the defensive and likely to go into “CYA” mode.

    To effectively understand and learn from the past the discussion has to be neutral and without blame or consequence. It’s a difficult concept for organizations to grasp. The key to blameless meetings is to conduct them as a regular occurrence rather than a response to a negative situation, and to foster a culture where failure is acceptable as long as it is used as a learning experience.

    Storms also suggests changing the name to “After Action Reports” to remove the negative stigma. “Postmortem implies a dead body. After Actions Reports are imperative after any event regardless of the type of outcome.”

    Start with Security

    Security is an Achilles heel of development in general, but the rapid pace of development in a DevOps environment makes it even more critical that security be integrated from the beginning. Failing to consider security is a disaster waiting to happen.

    Those responsible for security often don’t even know about a project until after it’s already in production. Storms cautions organizations, “Untested and unreviewed code or designs in production represent both a large security risk, but also a risk to the business and your customers. Security needs to be part of the SDLC (software development life cycle) and DevOps from day one.”

    DevOps is not a silver bullet. Nothing is. There are a variety of unique advantages and benefits that come from successfully embracing DevOps, but to realize them you need to start with a clear understanding of your own objectives, and how DevOps can be leveraged to help you achieve them.

  • Data Protection for Operational Reporting Platforms

    Data Protection for Operational Reporting Platforms

    Making real-time business decisions based on data from social, mobile and cloud platforms is a requirement in today’s world. That’s why an ecosystem of next-generation operational reporting platforms such as Spark, Apache Cassandra, Kafka, Docker, Mesos, Marathon and more have come to life. Enterprises are using these technologies to re-architect their data storage and processing frameworks to achieve lower costs, scalability and faster response times. However, as enterprises onboard business-critical applications on this next-generation technology stack, they need to prepare for failures or errors that may disrupt customer-facing applications.

    One of the key benefits that operational reporting platforms provide is real-time visibility, which allows businesses to make strategic decisions based on actionable insights. However, the new applications generate a large amount of data and archaic operational reporting platforms (those based on traditional data warehouses, data marts and ETL logic) are unable to catch up and, as a result:

    • Business decisions are based on stale data
    • Fragmented data increases the risk of errors
    • Multiple copies of data increase storage costs

    These issues have driven many progressive, data-centric enterprises to re-architect their operational reporting platforms. In this new architecture, Kafka serves as a persistent message bus that ingests data from relational stores and provides failure resiliency and message buffering. Spark or Spark Streaming may be used for transformation, aggregation and other lightweight stream processing. These processing nodes may be deployed in Docker containers. Finally, Apache Cassandra serves as a distributed data storage layer that provides linear scalability and high-availability. Kafka also enables the ability to add multiple data consumers such as Hadoop/HBase through Flafka.

    Datos IO - operational reporting platforms

    However, as enterprises adopt operational reporting platforms, they want to ensure that bad data feeds and human error do not result in data loss. Apache Cassandra natively replicates data but that does not provide the capability to go back in time to recover data efficiently and at scale.

    As enterprises onboard their critical applications to achieve development agility, scalability and lower operating costs, they must also explore data protection solutions that are specifically dedicated for scale-out databases.

  • New F5 Software Advances Application Security, Management, and Orchestration

     Industry-leading service programmability promotes flexible deployment capabilities, policy-based controls, and hybrid cloud support

    VIENNA, AUSTRIA, MAY 17, 2016 – F5 Networks (NASDAQ: FFIV) today introduced software-based solutions that enable customers to seamlessly integrate availability and security services, simplify device management, and better orchestrate IT infrastructure. To lower costs and boost efficiency, organizations are evolving toward more dynamic infrastructure models that combine physical, virtual, and cloud components. Supporting this transition, F5’s innovative, versatile solutions give customers the ability to take advantage of the benefits provided by traditional data center, cloud, and hybrid architectures.

    Today, F5 is introducing:

    • BIG-IP® 12.1 software, delivering leading application services with enhanced public cloud integration and more sophisticated security policies for on-premises and hybrid cloud environments
    • BIG-IQ® Centralized Management 5.0, providing expanded management for F5’s BIG-IP solution portfolio with significant scalability and performance advances
    • iWorkflow™ 2.0, enabling the orchestration of F5 services with SDN-focused solutions like Cisco ACI and VMware NSX, as well as continuous deployment scenarios using DevOps tools from vendors such as Ansible, Chef, and Puppet

    Programmable Application Services for Ultimate Flexibility

    With the release of BIG-IP version 12.1 software, no other Application Delivery Controller (ADC) vendor offers F5’s level of programmability across traditional, cloud, and hybrid architectures. F5’s new iRules LX™ technology marks a substantial advance in programmability, providing the ability to manipulate and selectively deploy service capabilities via Node.js, and includes easy access to over 250,000 community Node.js packages. These capabilities are especially important in delivering advanced functionality for web applications that require optimized throughput, scalability, and unique traffic steering services. In addition, a new plug-in for the Eclipse Integrated Development Environment (IDE)—commonly supported by other enterprise technology vendors (e.g., CA, Google, IBM, Oracle, Red Hat, and SAP)—enables the rapid delivery of reusable code that drives advanced functionality.

    Strong Policy-Based Security with Protection for Applications Everywhere

    The proliferation of Internet-facing applications has led to pervasive threats on business-critical web services, along with an increase in the sophistication of attacks. F5’s security enhancements allow organizations to more effectively ensure application availability and performance, resolve critical app protection gaps, and strengthen overall defenses. Today’s announcement reflects a number of new security capabilities, with highlights including:

    –          BIG-IP 12.1 enhances industry-leading web application defense via BIG-IP Application Security Manager™ (ASM) with unique, customizable bot detection methods that enable detailed analysis and extensive device ID tracking.

    –          BIG-IP ASM accelerates the blacklisting of malicious IPs in hardware at high rates for layer 7 threats, providing coverage until feed lists are updated.

    –          F5 gives visibility into HTML 5 WebSocket connections for comprehensive policy protection where other WAFs fail.

    –          BIG-IP Advanced Firewall Manager™ now offers enhanced capabilities that automatically mitigate L3–7 attacks upstream in the ISP realm and control SSH channel user-initiated actions with simple custom policy enforcement.

    Tight Integration with Leading Public Cloud Environments

    Application architects and developers must rapidly implement apps and services as part of a continuous deployment pipeline, while ensuring that they remain fast, highly available, and secure throughout. F5 solutions are designed to let customers use the same services in the cloud that they can in the data center. New technologies offer expanded support for AWS and Azure environments, including integration with AWS autoscale to dynamically scale app services, active/standby high availability across availability zones, and added F5 WAF capabilities for Azure Security Center.

    Powerful Management and Orchestration Capabilities for Simplified Operations

    For network architects and administrators, F5 has updated its BIG-IQ Centralized Management solution. The platform provides visibility, reporting, licensing, and management capabilities that simplify operations for F5 BIG-IP products, and now includes support for F5’s award-winning BIG-IP Access Policy Manager®. F5 is the only vendor that combines centralized, role-based management for application delivery, security, and identity management into a united framework. In addition, with this new version of BIG-IQ, customers can now simultaneously manage, update, and configure application services for up to 200 physical and virtual devices, and handle up to 5,000 BIG-IP licenses.

    F5’s new iWorkflow platform accelerates the deployment of applications by enabling the orchestration of network services, such as traffic management and security. Available as a virtual appliance, iWorkflow™ is a multi-tenant solution for deploying application delivery policies with BIG-IP solutions to support a variety of IT environments, including hybrid clouds. Using smart templates, policies can be deployed directly via the iWorkflow GUI, via third-party management solutions such as Cisco ACI or VMware NSX through connectors, or via other orchestration technologies such as Ansible, Chef, and Puppet with an SDK.

    Supporting Quotes

    “To better meet the needs of customers, we have made significant investments in security, management, and orchestration, along with the feature-rich software that supports our flagship BIG-IP product line,” said Karl Triebes, EVP of Product Development and CTO at F5. “Giving organizations the ability to integrate F5 with vendors and solutions such as AWS, Azure, Cisco, and VMware is certainly a priority, but we also have an eye toward making sure our offerings resonate with those using open source technologies like OpenStack, and agile infrastructure from emerging ‘born in the cloud’ companies.”

    “As application services and resources are abstracted across increasingly diverse environments, the ability to easily unify functionality and enforce policies throughout vendors’ offerings becomes essential,” said Brad Casemore, Research Director, Datacenter Networks, IDC. “Similarly, the ability for enterprise IT to programmatically tailor performance and orchestrate services is a necessity for organizational success with multi-vendor SDN and cloud deployments.”

    Availability

    BIG-IP version 12.1 software, BIG-IQ Centralized Management 5.0, and iWorkflow 2.0 will be available in the second quarter of calendar year 2016. Please contact a local F5 sales office for additional product and service availability information pertaining to specific countries.

    Additional Resources

    About F5

    F5 (NASDAQ: FFIV) provides solutions for an application world. F5 helps organizations seamlessly scale cloud, data center, telecommunications, and software defined networking (SDN) deployments to successfully deliver applications and services to anyone, anywhere, at any time. F5 solutions broaden the reach of IT through an open, extensible framework and a rich partner ecosystem of leading technology and orchestration vendors. This approach lets customers pursue the infrastructure model that best fits their needs over time. The world’s largest businesses, service providers, government entities, and consumer brands rely on F5 to stay ahead of cloud, security, and mobility trends. For more information, go to f5.com.

    You can also follow @f5networks on Twitter or visit us on LinkedIn and Facebook for more information about F5, its partners, and technologies.
    F5, BIG-IP, BIG-IQ, iWorkflow, iRules LX, Application Security Manager, Advanced Firewall Manager, Access Policy Manager, and DevCentral are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries. All other product and company names herein may be trademarks of their respective owners.

    This press release may contain forward looking statements relating to future events or future financial performance that involve risks and uncertainties. Such statements can be identified by terminology such as “may,” “will,” “should,” “expects,” “plans,” “anticipates,” “believes,” “estimates,” “predicts,” “potential,” or “continue,” or the negative of such terms or comparable terms. These statements are only predictions and actual results could differ materially from those anticipated in these statements based upon a number of factors including those identified in the company’s filings with the SEC.

  • The Beauty of Inheritance Architectures

    The Beauty of Inheritance Architectures

    Spoiler alert: This article is not about inheriting your great-grandparent’s estate. It is rather about how embedding the principles of inheritance into the architecture of your chosen DevOps toolset can yield exponential results. And yes, I realize that you, the customer, have little to do with what a vendor builds its tooling architecture upon. However, you, the customer, can vote with your feet, to search out products that offer features such as inheritance, rewarding vendors that have it and punishing those that do not. The simple question to address here is, Why should the customer care?

    Like anything that can grow, sustainability on scale is a key concern. How much will it cost me when I am maintaining 6,000 applications on this particular DevOps toolset, as opposed to the six applications I started with? You can also infer maintaining a higher number of technologies as having the same need. For example, if I need to maintain three different types of databases, two different middleware, four different hardware platforms on “x” different versions of operating systems … you get the idea. The larger the application portfolio (in sheer numbers of apps), or the more technically complex the portfolio (in sheer numbers of technology components in an app), eventually will drive you to worry about how easy it is to maintain these applications within your chosen DevOps toolset.

    The capabilities of your chosen set of DevOps tooling will govern the costs of both the initial adoption of your services as well as the ongoing maintenance of the application portfolios you serve. It is hard to sell the value of DevOps to the business when it begins to see a one-for-one increase in DevOps engineering staff for every new application or technology venture under consideration. However, one of the chief culprits in driving large DevOps support staff organizations boils down to the lack of an inheritance architecture in the tooling that was originally selected.

    Setting a Common Language

    So before we discuss how inheritance will benefit us, first let’s agree on a common vernacular of what an “application” is. When you say the word “app” to someone, you get a wide variety of responses on what that means—from something that sits on your phone to a cluster of things that sit on the mainframe. Let’s begin by examining what an “app” is by the effort it takes to onboard and then maintain it on our DevOps sets of services (regardless of platform).

    Consider for a moment the hierarchies by which we could describe software constructs. It is relatively easy to discuss how software works in terms of hierarchy. First, at the lowest layer, we could describe having multiple technology components (or the lowest level of a particular piece of technology that must be addressed in a build). Next, assembling these components together forms the picture of what a single application looks like. Finally, assembling multiple applications that have a common symmetry or common purpose together form a system or series of apps.

    An imperfect but quick example could be the Microsoft Org Chart component of its Office application(s). For purposes of example we will argue that Org Chart, Clip Art Manager and Equation Editor are all components of the application Microsoft Excel. To build a new version of the application Excel, we would have to deal with each of these individual components that, once assembled in our build, would create a new version of Excel. When you combine more of the apps—Excel, Word, Outlook and PowerPoint—you get the system, or series, called MS Office. (And, yes, I know this is a less than ideal example, but it is meant only to illustrate a point.)

    Assessing the Work Effort

    The reason for discussing software in this way allows us to begin to discuss the level of effort to automate it. By addressing the work effort to automate each component (by type), we can begin to estimate how long it will take to complete “the automation of software.” For example, if my homegrown application has a source code component, a configuration file component, a database component and a middleware component, then I have four components I must automate (or include in the build and deploy process) to assemble a new version of my application.

    This gives us a “least common denominator” language for assessing how much effort it takes to automate a given app. I have seen most common applications have only two to three components. But I have also seen several apps that, due to their unique architecture and construction, have 30 to 50 components a piece. Obviously, it is easier to automate an application with only three components than one with 50 components. The other factor we need to apply on the ease of automation is whether I have encountered this particular component technology before in my prior automation efforts.

    Let’s say, for example, that the application I am estimating contains Java component(s). If I have encountered Java automation prior to this, I should have constructed a template for Java type component automation that I can use for a situation just like this one. In this situation a familiar technology component is far easier to automate than a new one (or, rather, new to me). However, if this is the first time I have ever seen Java, then it may take me a bit longer to construct the template I want for this app, and for future apps I encounter, that also use this technology type.

    The Beauty of Inheritance

    Here is where inheritance begins to play its critical role. If my DevOps-build construction tooling includes inheritance, then I could construct a “master” template or framework for each type of technology as I encounter it. A master template for SQL databases or Oracle or DB2, as an example. Or, I could make a master template for WebSphere or SharePoint types of technologies—one master for each kind of programming language we have in my shop. You get the idea.

    Having done this allows me to have a limited number of master templates, in which I can maintain all the critical steps and processes my company wants me to do for a given technology type. If different business organizations or development organizations need a variation, they can create a “child” of my master and vary it according to their own needs. As long as the linkage is maintained to my parent/master template, I can make the big, overarching changes driven by corporate mandate, and the business unit can continue to vary items to their unique needs.

    Having inheritance in this instance allows me to roll out changes to an entire organization, such as, for example, a security patch or process, for a given technology by simply adjusting the master template of that component. Inheritance automatically flows my change down to all the “children” of my master and possibly to all their “children,” should the need arise. The alternative is having to go through the specific automation of each application that has the targeted technology component and updating it manually, hoping I don’t miss one, and hoping the steps I may need to adjust do not break the old automation instead of alter it the way I needed.

    Imagine having a WebSphere subject matter expert able to adjust every client application that uses your corporate installation of WebSphere by simply adjusting one master template. Or having a network guru, or database expert, be able to do the same for all applications that use their particular technology component all at once. Inheritance preserves the real-world need of having limited alterations of the same technology type within the same company, flowing down changes from parent to child.

    Having a one-size-fits-all is simply not practical. Using copy/paste requires repeating updates to each impacted template or framework manually. But having the ability to create offshoots from a main, and not lose the connection to the main, allows corporatewide alteration from a central point of control. The costs of maintenance or administration are formidable; inheritance can reduce them. This allows a much higher ratio of applications or technology components supported by a much lower number of engineering staff.

    A Wider Impact for Inheritance

    Inheritance is keenly useful in release orchestration software as well. Most vendors offer the cut-and-paste approach: you copy the last the release you did, alter it slightly and use it again. That might work for some organizations. But having an inheritance feature creates entirely new dynamics on how a release is constructed for a given line of business and how corporate governance can be implemented with minimal effort. In this case, a corporate master release template can be constructed, and child releases can inherit from the master all the main governance required without risk of omission.

    I realize inheritance architectures might not be at the top of your list when evaluating DevOps tooling solutions. But I would submit it is a strategist’s job (if you need one, let me know, I am looking 🙂 ) to point out how long-term sustainability can be greatly benefited by this architectural feature—even if the vendor would love nothing more than to steer you away from it. If you already have committed to a tooling solution, you may want to bring this up at your next vendor features performance meeting. If not, you should at least consider what having it means to your internal cost structure, and what not having it will add to the true cost of ownership of any proposed solution.

    To continue the conversation, feel free to contact me.

  • SourceClear Launches Free Security Product for Development Teams Building with Open-Source Libraries and Frameworks

     Offering Supports Popular Languages and Connects to Leading Development Tools; Identifies and Prioritizes Vulnerabilities and Licensing Issues; Gives Detailed Fixes

    SAN FRANCISCO, May 9, 2016 – SourceClear, the security company for software developers, today announced a free security tool, SourceClear Open, for teams building with open source. Available immediately at no cost and delivered as a cloud service, the new tool enables developers to identify what open-source libraries they are using, what vulnerabilities exist, which vulnerabilities actually matter, and what needs to be done to fix them. SourceClear Open complements SourceClear’s products that are currently deployed by some of the world’s largest companies, including BAE Systems, The Gap, DataStax and Zendesk.

    “I have spent 15 years watching talented, hardworking developers reinvent the world and then roll their eyes when asked to use traditional security tools. Developers always want to do the right thing, but have been faced with tools that generate more noise than signal. It became increasingly hard not to be frustrated by the status quo, so I decided to do something about it,” said Mark Curphey, CEO of SourceClear. “We’ve designed the SourceClear products specifically for teams of developers. With this release, we are ‘giving back’ to the community that helps us all build amazing software.”

    SourceClear connects easily with existing tool chains (languages, frameworks and build tools), and is a critical component of modern development processes. Powered by data science, a dedicated research team and a community research program, SourceClear identifies vulnerabilities well beyond those found in public and government databases. Tracking thousands of threat sources and analyzing millions of open-source library releases, SourceClear detects disclosed and emerging security threats.

    “Open source and DevOps have transformed the way we build software, and developers are being held even more accountable for security. With that responsibility, developers want tools that bring immediate value and don’t slow them down,” said John Viega, author of many security books, including the first book for developers on how to write secure software. “SourceClear delivers the information that developers need to view, understand, prioritize, and fix vulnerabilities that matter. That’s a powerful value proposition.”

    Integrated with developer tools like GitHub and Jenkins and supporting popular languages such as Java, Ruby, Python and JavaScript, SourceClear can be connected to repos, build systems or a developer’s desktop in minutes. SourceClear offers teams the flexibility to look at their code base or drill into specific repos, builds, branches or tags. Teams can share data and send results to issue tracking systems like JIRA. Developers and their security teams always have complete control as source code never leaves their networks, and analysis and results are always encrypted when being transmitted and stored.

    In addition to GitHub and Jenkins, SourceClear integrates with other leading source control management systems, including Bitbucket Server, GitHub Enterprise and OSS Git. SourceClear’s native build plugins for Gradle, Jenkins and Maven, as well as package managers like Bower, Bundler, NPM and PIP, ensure complete coverage every time a build is run.

    In addition to Open, SourceClear includes:

    • Registry: A free database of security knowledge in the world’s open-source libraries and frameworks, including a complete list of all publicly disclosed vulnerabilities.
    • Pro: Combines all of the functionality in Open with additional premium features and support to help both developers and security teams prioritize, manage and fix real security issues – drastically reducing false positives.
    • Enterprise: Extends the features found in Pro for large enterprise implementations with complex requirements.

    About SourceClear

    SourceClear is the security company for software developers. We are a team of software and security engineers helping software engineering teams build software, safely. We take care of security for open-source and third-party code so our customers can focus on their business: shipping features and delighting users. Headquartered in San Francisco, California, and with an office in Singapore, SourceClear is backed by Index Ventures and Storm Ventures. For more information, visit us at: https://srcclr.com.

  • Hello, Security. Meet Agile

    Hello, Security. Meet Agile

    Illumio Chief Commercial Officer Alan S. Cohen recently wrote in his blog, “Go, Slow and No: Bringing DevOps Speed to IT Security,” “There are reasons why security and risk professionals often react with a ‘no.’ When you are tasked with assessing and reducing risk, going fast might not be the first instinct.”

    Many InfoSec practitioners adhere to accreditation and certification programs such as ISO27001, SSAE-16 SOC and PCI compliance. This ultimately means they follow strict policies and procedures for software development. These procedures go through many gates, including risk analysis, design and code reviews, penetration testing and ITIL-based change-management processes. InfoSec teams live in a world where they have to plan their changes months in advance, and this world often is in direct conflict with agile development and DevOps concepts.

    Agile is all about focusing on flow and end-to-end cycle time, releasing very small changes fast, early and often. It’s not about the number of things in each sprint, but rather what’s needed now for MVP and iterating. For agile and security to be in alignment, there needs to be a fundamental shift in the principles and values that enable the business over governance and process.

    In particular, security:

    • Embraces some uncertainty. You will never build a perfect piece of software. The key is to build guardrails and to have the required adaptive enforcement and monitoring in place to capture and correlate metrics that help you quickly respond, evaluate factors of compromise and leverage your deployment automation to remedy risk exposures quickly.
    • Is part of the project team, either embedded or as an adviser. There must be a dedicated resource that understands the team’s mission of delivering value. Somebody on the team should be wearing the security hat, helping to guide each project.
    • Is a risk adviser inside the organization. Don’t compartmentalize information. There needs to be a culture of trust, sharing and transparency about potential vulnerabilities to the service.
    • Trusts the decision-making of engineering teams. Informed and capable engineers aren’t reckless with security decisions.
    • Is part of everything. It’s the design of the entire service and therefore is the responsibility of the entire team, not just the security team.
    • Improvements do not add complexity to the user experience. Security that degrades the user experience will force people into insecure practices.

    Bringing Agility, Security Together

    Embracing agility and DevOps opens the door to new possibilities that can improve security posture without hindering the business. Security will quickly discover a new set of best practices:

    • Look to microsegmentation software that is adaptive and intelligent, to replace manual management of firewall rules and policy.
    • Decouple security from the infrastructure to gain a continuous enforcement pipeline that adapts to new hardware, with strong versioning that proceeds in lockstep with product releases, monitoring and infrastructure configuration.
    • Build security into the service stack; don’t bolt it on afterward.
    • For change auditing, don’t rely on the change management database alone. This is highly prone to error and discrepancies. Look at the the git history integrated with the automated deployment system. Change management databases should be integrated with the git pull requests and commit logs. Infrastructure automation tools such as Chef and Puppet keep logs for unapproved change drift. Make sure those logs are being captured and reported on.
    • In the area of developer support, DevOps is enabling the self-service/self-responsibility revolution by building wrapper abstraction layers for engineering teams to consume infrastructure across public and private data centers, using interfaces such as chat to trigger administrative actions and query metadata information on their instances. These wrappers can also be harnessed to present security grading for every server instance, promoting awareness and corrective action to each individual owner. You can quantify the grade by looking at patch vulnerabilities, images used to build, inbound/outbound port rules and configuration standards.
    • For data at rest, data in motion and data in transit, everything should be encrypted, everywhere. For example, use Illumio SecureConnect to encrypt data in transit via IPsec between workloads. Automation and the right secrets-management infrastructure can enable frequent rotating of SSL certs and keys.
    • Every time you commit to the code base, run a set of very basic security tests via your favorite continuous integration tool. Use automated tests to ensure common security mistakes don’t leak to production.
    • Perform red team exercises as an attempt to gain access to a system by any means necessary. Try to mimic the same processes that a motivated attacker would follow to map out an organization’s infrastructure, perform reconnaissance at key physical installations, and then test the physical, cyber and social defenses all at once through a staged exercise.

    Security can become an enabler. It no longer has to be stuck being the department of “No.” InfoSec can now be the team-building tools and systems that enable development teams to do what they want in a secure way.

    About the Author / Alfred Garcia

    alfredAlfred Garcia oversees DevOps for Illumio, where he is responsible for all preproduction and production cloud/infrastructure engineering and site reliability. A technology and operations executive with more than 18 years of experience, Alfred is an aggressive advocate of DevOps and of deep operations and engineering collaboration, from design to code/test and release to production support.

  • CloudPassage Named “Most Innovative Cybersecurity Company”

    SAN FRANCISCO, CA–(Marketwired – May 05, 2016) –  CloudPassage today announced it has been recognized as the “Most Innovative Cybersecurity Company” in the 2016 Cybersecurity Excellence Awards, which are voted on by the more than 300,000 security professionals who participate in the LinkedIn Information Security Community. From nearly 200 cybersecurity vendors that were nominated, CloudPassage was selected as the winner of the mid-size company category, focused on the most innovative organization that has between 101 and 1,000 employees.

    “Enterprises are in the middle of a massive transformation of their IT infrastructure designed to let them move faster and stay competitive,” said Robert Thomas, CEO of CloudPassage. “Agile IT delivery models involve lots of automation, high rates of change, mixed environments and on-demand IT services. But traditional security tools don’t work with these modern IT environments. We’re winning recognition as a leader in the space because CloudPassage Halo is now a proven platform that enables this transformation.”

    CloudPassage Halo is an on-demand, security-as-a-service (SaaS) platform that deploys in minutes and automates a comprehensive set of security and compliance controls for servers in any combination of public cloud, private cloud or data center environments. The result is fast, effective security that solves problems of visibility, microsegmentation, compliance and speed of deployment.

    The 2016 Cybersecurity Excellence Awards honored individuals, products and companies that have demonstrated excellence, innovation and leadership in information security. Winners were selected based on the content of their nominations and the popular vote by the Information Security Community on LinkedIn, one of the largest online networks of cybersecurity professionals with over 300,000 members.

    As part of the company’s efforts to remain innovative, CloudPassage was recently awarded three patents that extend the scope of its original, agent-based, agile security model, making it the first company to obtain a U.S. patent for universal cloud infrastructure security.

    About CloudPassage

    CloudPassage® Halo® is the world’s leading agile security platform that provides instant visibility and continuous protection for servers in any combination of data centers, private clouds and public clouds. The Halo platform is delivered as a service, so it deploys in minutes and scales on-demand. Halo uses minimal system resources; so layered security can be deployed where it counts, right at every workload – servers, instances and containers. Leading enterprises like Citrix, Salesforce.com and Adobe use CloudPassage today to enhance their security and compliance posture, while at the same time enabling business agility. Headquartered in San Francisco, California, CloudPassage is backed by Benchmark Capital, Lightspeed Venture Partners, Meritech Capital Partners, Tenaya Capital, Shasta Ventures, Musea Ventures and other leading investors.

  • Continuous Delivery: The Atlassian Way

    Continuous Delivery: The Atlassian Way

    Sonatype’s Mark Miller (@TSWAlliance) caught up with Ian Buchanan (@devpartisan) for our 2016 DevOps Leadership Series. Ian discussed his experiences at Atlassian, including continuous delivery, ChatOps, and use of tools such as Bamboo, Nexus, Puppet and Datadog.

    https://www.youtube.com/watch?v=MgRaYKHGqeQ

    Buchanan: I’m Ian Buchanan. I’m a Developer Partisan at Atlassian, which is developer advocacy for our developer tools.

    Miller: Ian, most people know Atlassian from solutions like JIRA and Bitbucket.

    Buchanan: Yeah, I focus mostly on Bitbucket and Bamboo. Bamboo’s our continuous integration and deployment tool.

    Miller: Good. One of the subjects we talked a little about at dinner last night is how Atlassian is using Nexus. Can you give us some background on that?

    Buchanan: Yeah, that’s right. Well, we’re a big Java shop. We have been for a very long time and have a lot of Maven dependencies for external reasons; we also store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     We’re a big Java shop. We have been for a very long time … we store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     Miller: As far as a binary repository, are you using it for anything other than components?

    Buchanan: Not that I’m aware of. I know that we’ve recently started to get into Docker quite a bit and Nexus is a good fit for that as well. I don’t know the extent which we’re using Nexus for that purpose yet, as Docker’s still quite new for us.

    Miller: What does your continuous integration pipeline look like?

    Buchanan: It certainly varies by product in the details. Of course, we have our own continuous integration product, Bamboo. Bamboo is the most pervasive tool we have.

    For the Java stuff it’s pretty simple pipeline where libraries get built and published into Nexus so that they can be used downstream. We also have some interesting, newer cloud products that are built with Python. A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    Miller: Are you guys using continuous delivery in house for your workflow?

    Buchanan: We’re in an interesting position that I think I see a lot of companies in. We have some behind-the-firewall products (our server products) and then we also have cloud products. In the cloud side, continuous delivery is used when we want to go very fast. But we also have to balance that with the approach we take for our server products so that they don’t fork terribly. We have continuous delivery up until there’s a product delivered. At that point, there is another kind of pick up—where the cloud products engage with other things like Puppet and Ansible to configure the environments with products that other people can pick up and run on premises.

    Miller: I was talking to your team in San Francisco. How are you guys using ChatOps with HipChat?

    Buchanan: I’ve been talking about ChatOps for quite some time. We do a lot of very interesting things with ChatOps. They play a very important part of our continuous delivery pipeline in that we publish build results in there. People can see when pull requests are ready and check those out. We get to see what’s happening from production as well. We have integration with Datadog; it tells us some of the monitoring things that are going on. It’s not just information coming into the chat room. There are also commands that folks can issue to make the continuous delivery pipeline move along. There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

    _________________

     There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

     _________________

     Miller: Anything coming up in the future you guys are working on that’d be fun?

    Buchanan: Well, a lot of the innovation really happens at our quarterly “Ship It” events. That’s where our developers spend 24 hours doing whatever kind of innovation interests them. A lot of time is spent scratching an itch they have. Some of the things that I saw there were about having more information coming back upstream, not just into the chat rooms, but into JIRA where more of the longer-term tracking is going on. They’re experimenting a lot with putting more information into JIRA.

    Miller: Nice. Final question, if you were going to be a superhero, would it be Dev, Sec or Ops?

    Buchanan: I’ve played Dev roles and Ops roles and I almost feel like I know those much more. But from a lot of the sessions at DevNexus, I have to feel like Sec is the superhero. They’re the superheroes because they solve some unsolvable problems in a lot of ways. But I don’t feel ready to play that role at the moment, myself.

    Miller: It’s interesting. I agree with you that they are unsung heroes. Most of the time they just get hammered for what they’re doing.

    Buchanan: That’s true. Yesterday I was in a session about securing REST endpoints. The speaker went through problems with BASIC off , DIGEST off and J2EE—all of these things which we use in our products. At the end we’re left with, “What is the answer?”

    Well, the answer is that for each of these, there are different problems. So we have to identify the right context. We have to understand where some things are broken, know that those things aren’t perfect, and design for that imperfection. That’s a mindset that we have to carry through dev, ops and sec. I hope more security folks step up and start telling those stories.