Category: DevSecOps

  • All Systems Fail*

    All Systems Fail*

    Vince Lombardi once said, “It’s not whether you get knocked down, it’s whether you get up.”  But in today’s world of high velocity development and release practices, it’s also about how fast you can get up.

    Today, we are seeing more news about sites from major online retailers and service providers like HP, Target, PayPal and Neiman Marcus going down.  High site traffic, poor configurations, scalable architectures, and well planned recovery practices all come into play.

    But the best organizations have been failing repeatedly for some time now…on purpose.  Organizations like Amazon, Google and Netflix practice regularly for application, system and site outages.  In fact, Netflix has baked continuous failures into its operations through an internally developed Simian Army.  While it might seem unconventional at first, failing all the time allows them to succeed.

    Our CTO here at Sonatype, Josh Corman, often reminds us that “All Systems Fail*”.  For those that take this to heart and prepare for the inevitable, they can be better prepared to recover.  In fact, for the best prepared, recovery can be so seamless, it is a continuous part of their operations.

  • Bridging the gap between DevOps and Security

    Bridging the gap between DevOps and Security

    Security should be baked into the DevOps process, from tools to skills to collaboration. DevOps and security are not mutually exclusive.

    The problem with digital innovation is that considerations for compliance come later, after the product or service is on the market. From public cloud infrastructure to Internet of Things to mobile apps and even to DevOps, tough requirements like security aren’t built into innovators’ plans. Entrepreneurs are thinking primarily about shiny, new, fast and disruptive. Yet for the CIO and other chief executives accountable to customers, laws and financial markets, managing risk around sensitive data is top priority.

    DevOps processes are at the heart of business innovation: think Netflix, Facebook, Etsy and Nordstrom, all leaders in their sectors. Yet many of the popular DevOps tools and methodologies, whether commercial or open source, haven’t been optimized for the needs of enterprise security. An application running in a container, for instance, will still require attention around configuration to ensure application security.

    As well, many security professionals haven’t yet made the leap to understanding the changing best practices for security in this new world of cloud/agile/mobile IT. Some security experts have imposed barriers to DevOps, by resisting the switch to faster, more iterative development along with the public cloud.

    On the surface, the speed at which DevOps teams are approving and releasing code would suggest an increase in security risks to end users by eliminating rigorous security review phases. Yet managing security, as with testing, is in fact optimal when performed side-by-side with developers as code is being written. By integrating security, people and processes tightly within the continuous delivery cycle, DevOps can do a better job of eliminating loopholes and gaps in the code before production. DevOps tools emphasize the use of frequent and automated processes to improve software quality: also an ideal model for handling security testing and fixes. Determining the best way to merge security with DevOps is a work in progress. The following concepts can provide a framework for getting started:

    1. Use the best of DevOps for security: DevOps, with its focus on automation and continuous integration, provides a more holistic framework for security management. Start by considering security through every step of the development and production cycle. Security professionals can help developers root out design problems in the beginning – such as ensuring all data transport is encrypted. Integrate automated security checks into development, testing and deployment phases, and educate all team members about the importance of incorporating security thinking in their specific job roles. Security should no longer be the last process before committing the code to production.
    2. Investigate new DevOps and Cloud security tools: Fortunately, the security technology industry is ramping up quickly to the needs of DevOps security. Static Application Security (SAS) tools test for security when code is being written while Dynamic Application Security (DAS) tools test for interface risks. A few of the reputable systems include Checkmarx, Veracode and Parasoft. The third area of security automation tools covers penetration vulnerability testing, such as Nessus, developed by Tenable. Other contenders in this area include Qualys and OpenVAS. These tools can integrate smoothly into the software development lifecycle, such as by plugging into Jenkins. By adding automation, security is not only built-in, but doesn’t slow down the DevOps process.
    3. Getting buy-in from security teams: This might just be the hardest part. While developers are incentivized to go faster and do more, security professionals are incentivized to control, monitor and reduce risk. Meeting in the middle is definitely possible – but it will require some opinion shifting on both sides. Developers and product managers will need to understand the importance of working collaboratively with the security team, and in an accountable way. Security people can benefit from a more comprehensive understanding of security in the cloud. This should include continuous education on the new tools and services available today to manage risk and to deliver even higher levels of security than in the past – from better reporting, to API-based security and easier encryption at rest.
    1. Manage tool sprawl: The concept of self-organization is an important one in DevOps, because it fosters a spirit of flexibility and rapid collaboration. Yet this same principle can also lead to environments of dozens or even hundreds of different tools in use to manage deployment, configuration, QA and orchestration. That creates risks for visibility and monitoring as well as standardizing around security controls and access. Engineering leads should help strike a balance between too much and too little governance when it comes to tools and workflows by providing guidelines for tool selection. The DevOps automation infrastructure itself can introduce risks. If a hacker gains access to a tool like Puppet or Chef, he can modify any number of configurations and add new user accounts. Configuration and change management tools must be adequately secured and governed, lest they become a new attack plane.

    With the advent of DevOps, there’s an opportunity at last for security to become an integral and seamless aspect of innovation. We think it’s not only possible but critical to give security the attention it demands in the world of fast IT.

    About the Author/Kris Bliesner

    Kris BliesnerKris Bliesner is CTO and co-founder of 2nd Watch, where he oversees strategic and technical development of 2nd Watch’s cloud-based products and solutions. Prior to co-founding 2nd Watch in 2010, Kris held many top IT positions with companies including Microsoft and Ambassadors Group.

    Connect with Kris: LinkedIn, Twitter, 2nd Watch Blog.

     

  • What approach to application hardening is right for your organization?

    What approach to application hardening is right for your organization?

    There’s no shortage of readily available hacker tools and techniques and stories in the news about mobile app hacks for both the iOS and Android platforms.

    Fortunately, security solutions providers have responded swiftly and there are many approaches that one can leverage to harden an app that is “out in the wild.”

    For those of you who may not be familiar with the term, hardening is a key step at the end of any secure software development lifecycle process which:

    • Confirms that the app is running as designed at runtime
    • Thwarts hackers’ efforts to reverse engineer the app back to source code

    Which hardening approach is right for your app? To the uninformed purchaser, simple obfuscators are attractive because they are low in cost, require little training and are quick to implement. However, given the sophistication of today’s hackers, it is important for app developers to look beyond the surface and take a more strategic approach to choosing an application hardening solution.

    Below are four key factors that IT Security professionals should consider when evaluating application hardening solutions:

    #1: Value of your applications

    A key factor to consider is the level of investment your company is making in an app in terms of R&D and maintenance costs.

    • If valuable proprietary intellectual property such as algorithms or monetizable content is embedded within the app, you should consider the potential revenue loss to your company if the app is successfully hacked.
    • If the app processes sensitive information such as financial transactions, account information or authorization credentials, you should consider the potential loss of revenue through fraud and potential collateral damage that could occur if the app is hacked or Trojanized. Collateral damage may include penalties for non-compliance with regulations, expenditures on security upgrades, and even costs associated with crisis management communication campaigns to manage adverse publicity and restore brand value.

    There is a prevalent belief that encryption and basic obfuscation techniques in and of themselves are adequate measures to protect apps against hacking. String encryption and variable renaming form a beneficial security layer, but they are inadequate when used in isolation.

    Also, it is important to understand that not all obfuscation and encryption tools are created equal. Obfuscation is often confused with simple method renaming techniques and basic string obfuscation technologies, which can be quickly broken and easily reversed. Further, any encryption wrapper that applies the same measures of protection across all the apps it secures can be easily broken by determined hackers. Remember that once a wrapper technology is broken, every application secured by that vendor will be compromised.

    See chart 1 below for recommended protection techniques for Low and High Value apps

    Chart 1: Recommended Protection Techniques

    chart1

    #2: Scale and Sophistication of Attacks Your Apps Will Likely Face
    Minimal protections against counterfeiting and repackaging are built into the app distribution ecosystem — including measures such as:

    • Detection of jailbreak or root conditions that enable side-loading of applications, many of which are Trojanized.
    • Monetization libraries to confirm that only legitimate applications are downloaded through an app store and that they are correctly purchased or licensed. However, these libraries can and are often breached by cybercriminals.
    • Audit processes to validate that only legitimate and harmless apps are placed in the app store. Audit mechanisms to block illegitimate apps from distribution to users are far from perfect, as seen by recent iOS malware, including XcodeGhost.

    Consequently, it is important to determine the scale and sophistication of attacks that you anticipate for your applications, and validate that the security solution you rely on is capable of meeting the challenge. For small-scale developers with free- or ad-supported apps, typically basic application protection will suffice, even though ad revenue may be subverted through Trojanization.

    In contrast, for business-critical enterprise applications, it is safe to assume that an organized army of hackers will be actively looking for ways to subvert your app as quickly and as comprehensively as possible. Since such attacks are designed to be covert, it can take weeks or even months until evidence of a successful hack surfaces. For that reason, measures of defense against attacks have to be complemented by measures of detection and reaction. For example, deeply instrumenting an app to detect attempted attacks and react with functions such as “phone home” can provide long-lasting and durable protection.

    Consider the recent benchmarking study that analyzed an Android Java mobile payment application that was hardened with a comprehensive protection solution against the same application with a Basic Java protection solution. Key findings from the study appear in the chart below:

    Chart 2: Strength of Protection of Basic and Comprehensive Hardening Techniques

    chart2

    Attacks that systemically compromise the underlying libraries an app relies on are the fastest growing class of attacks – and presently the most dangerous. This makes it imperative that high value apps are able to verify the pristine nature of their entire execution environment before unlocking sensitive functionality. Obfuscation solutions that focus solely on variable renaming or string encryption can deter static reverse engineering but are not able to protect against the full spectrum of high-intensity attempts to compromise the app.

    #3: Agility and Portability

    The portable device ecosystem, spanning smartphones and tablets and wearable devices, is among the fastest growing and fastest evolving. In stark contrast to the PC ecosystem — which is dominated by only a few chipset and operating system combinations, the portable ecosystem is a combinatorial nightmare of chipsets, OSs, programming technologies and hardware functionality.

    Because it is likely that mobile platforms will continue to evolve at their current breakneck and unpredictable pace, choosing a solid security partner with a history of innovation- that can keep pace with evolving ecosystems- is crucial. Additionally, selecting a security tool that is designed for cross-platform portability and extensibility will go a long way in helping you adapt to new platforms that become available.

    #4: Overhead and Performance Impact

    Memory footprint, power consumption and performance are important considerations in portable devices, where resources are limited and battery life is precious. All security technology will impose an additional memory footprint in storage and at run-time. It will also impose process overhead in terms of programming effort, compilation complexity and run-time execution characteristics.

    That said, more sophisticated application hardening solutions can offer a stronger trade-off between performance impact and protection strength relative to free- or low-cost solutions. For example, brute-force simple obfuscation can quickly cause memory bloat and diminish execution speed, while basic check summing can adversely impact run-time performance while retaining single points of protection failure.

    When apps are deployed to millions or billions of users, and/or where transaction volumes are expected to be high, it is crucial that the security solution chosen be as robust and reliable as your own app code. Obfuscating sections of the code that are sensitive to performance degradation, such as computation-intensive functions or graphics rendering routines, has an impact on runtime performance. It’s paramount to choose a protection solution that offers tunable performance vs. security tradeoff measures, and provides developers better control on size and performance of their code.

    The rise of mobile computing and soaring app usage has companies of every size and caliber scrambling to keep up. With customer loyalty and revenues at stake, developers are scrambling to release cutting-edge apps with little thought for long-term security considerations. In these conditions, it is tempting to treat code hardening as a checkbox and select the cheapest, most readily downloadable tool to do the job – but let the buyer beware. If you take the time to assess the value of your applications and the available options, you’ll realize that if you have a high value app and focus solely on cost, you are likely to be “penny wise and pound foolish.”

    About the Author/Patrick Kehoe

    PatrickPatrick joined Arxan in January 2014 as Chief Marketing Officer. Mr. Kehoe has over twenty years of experience building and managing sales and marketing capabilities for software, hardware, and service providers in the High Tech industry. Over the past three years, he held leadership positions at Siemens Enterprise Communications (SEN) – a global provider of communications software and services. Most recently he was responsible for North American marketing and partner business, where he oversaw the development of the strategic plan and drove Market Awareness, Pipeline Generation, and Sales results. Previously, he managed SEN’s Global Marketing Strategy, Intelligence, and Operations. Prior to SEN, Mr. Kehoe held positions at Booz Allen Hamilton and MarketBridge, a Sales and Marketing Professional Services Firm, where his clients included: IBM, SAP, Symantec, and VeriSign. Among other areas of focus, he was responsible for market expansion, new product marketing, digital marketing, and social media. Mr. Kehoe has a track record of success in North America, Europe, South America, and Asia, and has spoken at conferences and corporate events on a variety of sales and marketing topics. He holds a degree in Computer Science from Vanderbilt University and a MBA from the Darden Graduate School of Business, University of Virginia.

  • Combining SecOps and DevOps

    Combining SecOps and DevOps

    Security has to be top of mind for most any company that is moving, or has moved, to the cloud. And, businesses know they need to act swiftly to ensure that any new products or services they’re dreaming up do not expose them to risk.

    How can they do that when the fast-moving nature of the cloud is leaving proper security practices in the dust? The problem today is that today’s security solutions are proprietary, too slow and take too many resources.

    Bottom line, the security model that has served most businesses well was never built for speed, and is simply unsustainable for opportunities in today’s cloud-centric world. Today, security solutions must be agile, lightweight, loosely coupled and extensible.

    On the front lines at various companies you’ll see a new type of cooperation –  where two teams most directly involved in a potential solution, development and security – are breaking down the traditional (and often opposing) silos and collaborating more openly to drive secure innovation from the start.

    We’re seeing a new “marriage” of SecOps and DevOps that creates a whole new mentality for driving innovation inside and outside of organizations. This new mentality allows security and DevOps to find common ground to make it easier for organizations to align their security goals with the delivery of their products at today’s rapid speed of business.

    While businesses are changing internal structures to address cloud security, there are also a number of new solutions that can be deployed against a company’s clouds and deliver security intelligence back to the DevOps teams.

    These kinds of tools are especially important for start-ups and SMBs that face unique challenges securing their businesses from cyber attacks and preventing data breaches.

    By encouraging greater collaboration between security and DevOps, and relying on outside solutions to assess and identify potential threats as new products and services are developed, businesses of all sizes can feel a higher level of confidence that they’re addressing security concerns by enforcing industry-leading security practices every step of the way.

    About the Author:/Tim Prendergast

    tim p Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.

  • Avoiding Common AWS Security Risks

    Avoiding Common AWS Security Risks

    According to IBM’s Cyber Security Intelligence Index, 95% of all security incidents involve human error. That’s beyond significant, and when rapidly deploying multiple iterations in a DevOps shop, that means there are lots of opportunities to fail.

    Our own independent analysis based on customer configuration data shows that security control mechanisms Amazon Web Services (AWS) makes available to its customers are not always being used consistently due to human error, creating unnecessary security exposures while operating workloads in cloud.

    In this article, we’ve highlighted the five of the most common AWS security risks detected in the first half of 2015, and share simple steps you can follow to address them.

    EBS volumes are missing optional EBS volume encryption…

    EBS volume encryption uses AES-256 and is a convenient mechanism for meeting data-at-rest encryption compliance mandates. An unencrypted EBS volume cannot be converted to an encrypted volume after creation. It is a setting that must be applied on creation of an EBS volume.

    EBS volumes contain no snapshots less than two weeks old…

    Snapshots are a low cost way to recover EBS volumes and they can be made while a system is online. We have seen a number of occasions where clients have benefited from snapshots in IR scenarios by enabling them to forensically analyze systems that had been compromised from recent snapshots in virtual private cloud sandboxes.

    Unused EC2 Security Groups…

    Keeping your EC2 security groups clean eliminates the risk that an unauthorized security group policy will be used by mistake to open attack surface. Often clients have had relatively new AWS users mistakenly launch EC2 instances using insecure security groups that lead to incidents. Practice good security hygiene and remove your unused EC2 security groups.

    Unused or unmaintained ELB Security Groups…

    Keeping your ELB security groups clean eliminates the risk that an unauthorized security group policy will be used by mistake to open attack surface. In large multi-tier architectures, ELBs frontend fleets of backend systems, and ELBs have security groups that should use authorized security group policy. Practice good security hygiene and remove unused ELB security groups.

    Global permissions to access TCP or UDP ports in a security group that is attached to an active instance/ELB…

    Restrict access to known static IP addresses or CIDR ranges within your control. Many clients have experienced scenarios where they found themselves conducting incident response efforts due to unauthorized EC2 instances that were launched using insecure globally accessible security group policies. Monitoring active security groups enables clients to shorten time to detection and time to remediation of firewall related vulnerabilities and enables clients to minimize attack surface.

    About the Author/Justin Lundy

    justinlundyJustin Lundy, CIO & CTO, co-founded Evident.io after leading Adobe’s Cloud Security efforts to identify, implement, and manage security controls and strategies during rapid adoption of the cloud at scale. He has spent more than a decade in the infosec industry, and is a subject-matter expert in multiple domains. Justin previously defended the castle at Adobe, MTV/Viacom, Sun, and CA.

  • AWS re:Invent – New Releases Drive Cloud Security Innovation

    AWS re:Invent – New Releases Drive Cloud Security Innovation

    The recent AWS re:Invent conference in Las Vegas saw the release of several new AWS services for security. Some of these announcements such as AWS Web Application Firewall and AWS Inspector seemed to take many in the security press and blogosphere by surprise.

    Cloud-native security companies like Evident.io however, weren’t surprised by these announcements. In fact, AWS has been actively partnering with their security ecosystem to create opportunities for partners to innovate on top of these new base services.

    Both incumbent and emerging partners need to remember that a platform is not a product, it is a constantly growing and evolving entity that will continue to adapt as the cloud ecosystem continues to change.

    If you want eternal stability, consider investing in a pet rock. If you want to be part of continuously improved technology ecosystems, then strap in because AWS is the rocket ship of platforms in this space.

    AWS, no matter what they innovate, will encroach on similar value positions of its ecosystem as a matter of existence. However, this is the best situation possible for customers of the platform.

    Customers win out because they receive constant technology innovation and improvement as part of their platform experience, which is something that was never present in the datacenter ecosystem.

    Let me paint some color to what these services mean for the ecosystem:

    AWS Web Application Firewall (WAF)

    AWS WAF enables customers to create filtering rules that whitelist or blacklist application calls coming inbound from the internet towards a customer’s deployed CloudFront CDN resources.

    For example, a customer could write a WAF Rule that filters requests to their web application based on source IP address matching or pattern-matches against the request string.

    If I was running an e-commerce store that only sold products to the US, I would ensure that my WAF rules contained blocking request patterns for IP Address ranges from China, Syria, Sudan, North Korea, and other embargoed countries (and huge sources of malicious traffic).

    While this appears to be a direct attack on some cloud security providers, it really creates a new market path and opportunity for them to deliver their WAF intelligence to the customer.

    Let’s be honest — there’s nothing differentiating about building a big x86 appliance and having it run the rules intelligence for your infrastructure.

    AWS has removed that barrier of virtualizing the appliance and created a direct path for these companies to deploy their core value proposition — curated and powerful rulesets that protect customers from historical, existing, and future attacks.

    Expect to see branded rulesets available through some kind of marketplace or other delivery mechanism here, as that is what customers need.

    AWS Inspector

    Inspector, in our eyes, was the most important announcement in recent AWS history. We’ve finally seen the true convergence of cloud-based security begin to emerge: Continuous API-centric security intelligence accessibility that is pervasively built into the platform’s diverse feature-set.

    With the advent of Inspector, security providers can directly interface to the hosts and applications to provide deep, thorough security visibility for customers without deploying additional third-party agents.

    Let’s face it, customers were already overburdened with agents before they ever got to their security stack, and the value delivered by security agents has been questionable at best in cloud environments.

    Expect security platforms to integrate singular-views of workload-wide security intelligence in order to provide customers a complete picture of their security posture, risk profile, and attack surface.

    Config Rules

    Config Rules was, perhaps, the least exciting of AWS announcements in the security space. Unfortunately for Config-based service interactions, the limitations of the service are still apparent a year after initial launch.

    Config Rules offers no exception, where interesting capabilities for customers to define custom rules that help them understand what changes impact security in their environment are hampered by limited service support, a cost model that is too unpredictable for small customers and of minimal security value beyond the “ping” that happens when rules fire.

    These challenges are compounded by the barrier to entry of writing well-structured and contemplated security rules by a broad audience of non-security experts, which delivers an almost false sense of protection.

    Contrasted with CloudTrail, which gives valuable audit information that makes sense at an operational level, Config Rules anticipates the customer will have strong security experience and operational knowledge to leverage the service.

    But some customers in every user base are satisfied with what we call “good enough” security in the industry, which defines a scope of offerings that barely make the cut to be called security technology.

    The platforms and vendors slinging “good enough” security tend to be at the international buffet, where you get a below-average pizza, a mediocre taco salad, and a poor hamburger.

    Nothing you get leaves you with a feeling of being satisfied, because not enough effort was put into the final product to actually change the way you think about the experience.

    But mature, focused products will always deliver a superior customer experience, and in security that should never be considered optional.

    A vendor who divides their attention between cost management, security, optimization, etc. will never provide the same quality or attention to protecting your infrastructure as a focused innovator in the space can offer.

    Users can expect a waiting period for service support for new AWS services, meaning that your security controls are dependent on Config’s roadmap.

    But security savvy customers, are not keen on waiting for security to grow up around them – they need it now, they need it on 100% of their cloud infrastructure, and they need it to be actionable.

    This is why many will continue to choose the leaders in each security layer over the basic security features tied into the platform itself.

    Expect Config Rules to grow over time – but if Config is any indicator, it will be a long time before Config Rules provides real value for customers on the platform.

    The real value here is that innovators in the security space will continue to fill the gaps left by services in the platform and innovate customer value atop the technology that does make the cut.

    Wrap-Up

    Well, that was a journey – and we only covered three services! AWS re:Invent 2015 was a whirlwind of sessions, 19k participants, and awesome discussions on every topic under the sun.

    It’s hard to believe we have to wait another year to see this massive gathering happen again, but that leaves a lot of time for innovation, new customer success stories, and to sort through the giant piles of swag that everyone picked up in that madhouse of an expo hall.

     

    Author: Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.

  • Upcoming SANS Webinar: Orchestrating Security in the Cloud

    Upcoming SANS Webinar: Orchestrating Security in the Cloud

    Organizations are increasingly migrating to cloud-based services to handle sensitive data and business processes, meaning security teams need to carefully review and understand what security controls are available to help protect them.

    Given the pace of cloud adoption, security teams need to increase security automation efforts and employ tools that can better secure their cloud assets through improved visibility.

    SANS is hosting an informative webcast on Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) to present the findings from a new survey that examines the organizational use of public and private clouds and outlines best practices for assuring a robust security posture.

    The webcast is scheduled in conjunction with the release of the highly anticipated SANS whitepaper on cloud security titled Orchestrating Cloud Security (PDF), written by analyst and network security specialist Dave Shackleford.

    The whitepaper presents the results from a survey 485 IT professionals who use different cloud providers and service models for a variety of business needs, including collaboration services, email, managed services, backups for disaster recovery, and other common use cases for cloud services.

    Although cloud services provide the functionalities businesses need today, the survey reveals that they also come with inherent security risks.

    The SANS survey found that 40% of the respondents acknowledge they process sensitive data in the cloud, and are facing increasing challenges related to access control, configuration management, compliance demands, overall visibility, and the implementation of security controls.

    New technologies are emerging as part of the security-as-a-service (SecaaS) model, which are security-oriented cloud-based services that integrate with provider platforms to protect data in cloud ecosystems.

    “Although many controls are still managed internally, SecaaS is emerging as a viable means to enhance security in the cloud environment. Security teams should start considering the use of SecaaS options when designing and architecting cloud security models,” the SANS survey notes.

    In the upcoming webcast, Shackleford will be joined by myself (Evident.io’s Andrew Maguire), Intel Security’s Margaret Diego, CloudPassage‘s Sami Laine, and Mark Painter from HP Enterprise Security to discuss:

    • How organizations use the cloud
    • What types of information they store in the cloud
    • What concerns they have about data security
    • How much they rely on cloud service providers and what difficulties they face
    • What security and data protection technologies they use in the cloud environment
    • How they manage cloud users
    • And much more

    The SANS survey clearly highlights and validates the challenges of cloud migration across companies of all sizes. Organizations moving workloads to cloud architectures such as Amazon AWS understand the flexibility and cost efficiencies gained – but often struggle with new best practices and the shared responsibility needed to maintain a secure cloud-computing environment.

    The porting of traditionalsecurity technology and Agent-based solutions used in the past do not translate well to cloud environments, leaving customers with too much data and poor visibility into critical service configuration or controls that could eventually lead to compromise.

    Webcast attendees will be among the first to receive the whitepaper. Join us Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) for this timely and informative webcast!

  • Alert Logic Cloud Insight brings cloud-based security to your cloud infrastructure

    Alert Logic Cloud Insight brings cloud-based security to your cloud infrastructure

    One of the primary driving forces behind DevOps is its fluidity. There is a domino-effect that cascades from the developers who create the apps to the IT admins who deploy and administer the apps to the individuals who download and use the apps and back again. Traditional security can’t keep pace so Alert Logic created Cloud Insight—a cloud-native vulnerability and configuration management solution for cloud infrastructures running on Amazon Web Services (AWS).

    I’ve written previously about the continuous continuousness of DevOps. Anything and everything that used to be manual tasks on a static infrastructure is now automated to the Nth degree. “Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change.”

    All of that also means that it’s virtually impossible to keep up with the current configuration or accurately assess vulnerabilities in a constantly-changing environment. If your entire cloud infrastructure can change at the push of a button you also need to have security controls in place that are just as automated and capable of flowing with the changes and providing continuous, real-time security. Traditional security solutions simply won’t work.

    Alert Logic agrees, which is why it developed Cloud Insight. Gray Hall, CEO of Alert Logic, explained in a press release announcing Cloud Insight, “Managing security while maintaining the agility of the cloud is fundamentally different than in any other environment. With Alert Logic Cloud Insight we are delivering an innovative solution that gives businesses an added layer of visibility for workloads running on AWS—actionable intelligence to identify and eliminate risk across instances and applications while not slowing the business down.”

    Cloud Insight automatically tracks changes—additions, moves, deletions—within the AWS platform. It continuously identifies threats and vulnerabilities and potential exposure to risk within the dynamic environment. Alert Logic uses AWS APIs to integrate with the cloud infrastructure to detect any changes and inspect the new, change, or modified resources for vulnerabilities or configuration issues.

    Cloud Insight generates a prioritized list of remediation actions so the organization knows in real-time what’s broken and what the exposure to risk is and it can focus on addressing the issues and maintaining a strong security posture rather than spinning its wheels just trying to keep up with vulnerability assessments in a fluid environment.

    Terry Wise, VP of Worldwide Partner Ecosystem for AWS, said “Security-as-a-Service solutions built on AWS and designed to complement AWS-native security features enable customers to maintain the highest levels of protection while achieving the agility, elasticity, and cost savings of the AWS Cloud.”

    Alert Logic Cloud Insight is pre-approved to run on AWS. You can use Cloud Insight to conduct vulnerability scans and penetration testing within AWS without any additional permission. Cloud Insight also includes customer-facing APIs that can be used to integrate with other DevOps tools, and it can be integrated into your existing DevOps pipeline.

    Pricing for Alert Logic Cloud Insight is similar to the AWS pricing model. It functions on a pay-as-you-go basis based on the number of hosts or protected instances for a given day. Customers are billed $1 (USD) per instance per day. You can request a free trial of Alert Logic Cloud Insight to determine if it’s a good solution for your organization before taking the plunge.

  • Alert Logic lends more agile, cloud-native security to DevOps architects

    Alert Logic lends more agile, cloud-native security to DevOps architects

    Amid the avalanche of research and product news emerging from this year’s Black Hat USA 2015 conference, held in Las Vegas this week, at least one vendor is attempting to advance a new solution aimed at empowering DevOps architects to streamline and improve security workflow.

    Houston-based Alert Logic announced the release of its Cloud Insight solution on Tuesday, positioning the offering as a cloud-native vulnerability and configuration management package designed for customers running on Amazon Web Services (AWS). Cloud Insight promises to integrate with AWS native security features, providing an integrated view of potential host and application-level vulnerabilities.

    By empowering operational teams, including DevOps architects, to identify and move to remediate vulnerabilities before affected applications code is pushed into production, company officials claim, the solution promises to both improve the configuration of resulting infrastructure and remove obstacles related to traditional cloud security management.

    “This solution is specifically aimed at helping AWS users who are not security professionals, such as operations and DevOps teams who deploy the infrastructure, address inherent security issues,” said Rahul Bakshi, Senior Director of Product Management at Alert Logic.

    “When you think of rolling security into the existing model, typically it interrupts the notion of continuous deployment, as historically it hasn’t integrated via the application or plugged into automated orchestration systems, becoming a hindrance,” Bakshi said. “That’s where this approach introduces a significant advantage, allowing organizations to identify and fix high risk vulnerabilities before the code gets pushed to production.”

    Unlike traditional vulnerability management specialists, such as Qualys or Tenable Network Security, which require users to manually configure and review data and provide only a “partial” view of cloud platforms such as AWS, Alert Logic claims that Cloud Insight lends critical automation to involved processes and allows ops teams to gain far deeper visibility into AWS services level security.

    Alert Logic has already won some customers over with its ability to enable greater control over applications security in the cloud. Speaking at the annual AWS Summit, held in San Francisco in April, Colin Bodell, Chief Technology Officer at publishing giant Time Inc., highlighted some of the work his company has done leveraging the vendor’s existing Security-as-a-Service offerings.

    “AWS is great for physical security, or for network security, but when you’re building an application you need to own security of the application yourself,” Bodell said. “AWS doesn’t know how you’re building things and you can build them in any weird and whacky way that you like; Alert Logic has been an amazing partner.”

    In the recent report, “Market Overview: Cloud Workload Security Management Solutions – Automate or Die”, published in June, analysts at Forrester Research highlighted the specific need for new security methodologies that integrate and automate processes to stem potential DevOps bottlenecks.

    “One of the key benefits of DevOps is to enable continuous integration of code and continuous delivery of apps and infrastructure,” the Forrester report notes. “To keep up, [security and risk management] pros must make security processes more embedded, faster, and more continuous – otherwise, security will slow down code release.”

    In terms of bringing Cloud Insight – which exists as a solution, rather than a SaaS service offering – to market, Alert Logic claims that it is successfully appealing to organizations’ hopes to embed AWS vulnerability management further within operations, despite introducing an altogether new and unfamiliar approach.

    “Beta customers seem very positive as we’re reducing the security workload and time related to remediation handoff for cloud architects,” Bakshi said. “There’s always a continuum for education, but with the culture of responsibility [for AWS security] evolving, we think that we’re meeting demand at just the right place.”

    Dan Raywood, Analyst at 451 Research, said that Alert Logic could take advantage of related demand by leveraging the combination of its existing cloud security expertise along with capabilities added via its January 2015 acquisition of Critical Watch.

    “I think it’s a very interesting move for them as even though they did have something offering this‎ type of scanning previously; the acquisition of Critical Watch added the engine to do continuous scanning and change management,” said Raywood. “The major bugs of the last year have driven business to assess and respond immediately, and having something which tells you if you are vulnerable or not a few clicks away is a really useful tool for businesses.”

    About the Author/ Matt Hines

    matthinesMatt Hines has over 18 years as an IT marketing/communications professional at companies ranging from ground-floor startups to established industry leaders with emphasis on advancing broader understanding of key technology industry trends, market drivers, customer requirements and innovative products to highlight value, increase awareness and drive revenue growth. Additionally Matt has a decade-plus writing in IT journalism covering leading trends for a wide array of industry-leading business technology publications including eWeek, InfoWorld, CNet and TechTarget. You can reach him on LinkedIn

  • The Software BOM Squad

    The Software BOM Squad

    In my previous post, “When Good Code Goes Bad“, I shared new research showing the average large development organization consumes over 15,000 known vulnerable and defective components annually.  While we can’t stop software from going bad, there are practices from traditional manufacturers that we can use to improve our ability to recall and fix the “bad” software components.

    The Software BOM

    A Bill of Materials (BOM) is used in traditional manufacturing supply chains to list the suppliers and parts used in a product, a “software bill of materials“ (BOM) is an inventory of the third party and open source components used to build an application.

    Screen Shot 2015-07-17 at 10.06.03 AM
    A sample software bill of materials lists all open source and third party components, including their version, age, license type, and any known security vulnerabilities.

    As noted in Wikipedia, “The concept of a BOM is well-established in traditional manufacturing as part of supply chain management.  A manufacturer uses a BOM to track the parts it uses to create a product. If defects are later found in a specific part, the BOM makes it easy to locate affected products.

    “A software BOM is useful both to the development organization (manufacturer) and the buyer (customer) of a software product. Builders often leverage available open source and third-party software components to create a product; a software BOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use a software BOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Understanding the supply chain of software, obtaining a software BOM, and using it to analyze known vulnerabilities are crucial in managing risk.”

    A software bill of materials not only inventories what is used, but in some cases it also syncs with real-time component defect data to indicate which components have known vulnerabilities or license risks. Various software supply chain automation tools expand the bill of software much further, alerting stakeholders automatically when a defect alert occurs. In advanced tools, the entire software lifecycle is automated to ensure that defective components are avoided and continuous monitoring instantly identifies newly announced vulnerabilities as soon as they are discovered.

    Breaking Bad

    As mentioned in my previous post, When Good Code Goes Bad, there is no way to prevent software from “going bad”.  No one is immune from these issues.  Therefore, we need to focus on our responses to these issues.

    To paraphrase Vince Lombardi, “It’s not how you get knocked down, it’s how you get up”.  Following the OpenSSL vulnerability announcement in 2014 (or pick any other new security vulnerability with or without an assigned logo), every development and IT operations team on the planet was asking two questions:

    1. Did we ever use that open source component?
    2. if yes, where is it?

    For those organizations tracking their use of components with a software bill of materials, the answer was easy to find.  For other organizations, weeks and often months of research were required.  To get a sense of the lack of maturity around traceability practices, take a look at this image from Sonatype research showing announcements of OpenSSL vulnerabilities in products following the initial vulnerability disclosure in April 2014.

    Screen Shot 2015-07-17 at 10.07.09 AM
    Automating Traceability Across the Software Supply Chain

    Software supply chain complexities, coupled with the volume and velocity of open source and third-party components flowing through them, are forcing us to think differently about our current practices across development and operations.  We are not the first to face these challenges and we can learn a great deal from the mature practices of  other high-velocity manufacturing organizations and industries.

    One thing is certainly clear.  Manual practices of monitoring or occasional checkpoints cannot keep pace with volume and velocity of components being consumed.  And if you extend these considerations beyond just open source components and into containers, microservices, or other images used in development and operations, the problem is further out of reach for manual processes to keep pace. The volume and velocity within our software supply chains will not diminish—and without a new approach, the volume of unchecked quality and integrity of parts being consumed will continue to build up as technical debt.

    But the answer is here today: automation.  Automation can unleash the potential of an organization’s development capacity. Rarely is there such an opportunity to simultaneously increase speed, efficiency, and quality. Solutions that facilitate comprehensive software supply chain automation are poised to usher in the next wave in development productivity—with gains on par or even greater than possible with agile, Lean, and DevOps.

    More information on the current state of software supply chain practices as well as examples of best practices being employed by software development teams, can be found in the 2015 State of the Software Supply Chain Report.

    Screen Shot 2015-07-22 at 9.26.05 AM