devopsy.kinsta.cloud

Category: DevSecOps

  • Application Development: Ripe for Encryption

    Application Development: Ripe for Encryption

    As businesses look to accelerate application innovation and move more and more workflows to the cloud, their needs can be at odds with the need to secure the data. This article will outline current challenges faced by application developers to protect data in this new cloud/DevOps environment. It will also provide insights on how to eliminate the burdens from the DevOps team while significantly improving the security of data stored in cloud databases.

    Cloud Migration

    Businesses are looking to accelerate application innovation and move more workflows to the cloud.  Cisco’s Global Cloud index projects a 26 percent growth rate of cloud workloads between 2015 and 2020. As this trend accelerates, IT project owners increasingly run into audit and compliance requirements that prevent transfer of sensitive data outside the traditional security perimeters. The overwhelming benefits of the cloud including the ability to obtain unlimited scalability of infrastructure, set up and tear down rapidly and gain cost advantages due to economies of scale make this trend impossible to contain.

    Application Development Challenges in the Cloud Era

    As applications migrate to the cloud, application developers are using microservices to accelerate application development because they dramatically reduce development time and help them focus on their key value proposition, be it hailing a cab or booking a place to stay. The success of microservice players including Twilio and Braintree demonstrate the benefits of delegating non-core features such as calling, messaging and payment processing to domain experts.

    Surprisingly, when it comes to something as critical as data security, enterprises still leave the burden on the application developers. This distracts them from working on business objectives as they worry about security problems such as how best to encrypt at data and when to change encryption keys—problems best handled by security domain experts.

    Securing Cloud Workloads

    As it turns out, encryption is not easy to incorporate into enterprise workflows. Encrypting application data prevents databases from processing it. Then there is the problem of managing keys, which could be lost or become stale. Encrypting cloud workloads brings a whole new set of challenges as the issue of control comes up. If the cloud vendor has access to the keys, what prevents them from being subjected to a subpoena from a government that is using national security as justification to decrypt the data? Add to that the complexity of migrating from on-premises databases to the cloud without risking the data.

    Pragmatic Approach

    A pragmatic approach to solving this problem is to use existing encryption solutions that provides the detection, classification, policy enforcement and monitoring of sensitive data at all times. These solutions can protect application data at a columnar level but easily integrate into existing enterprise workflows. Application developers can identify sensitive data based on a data classification matrix and the sensitive data is automatically protected as it is inserted into the database. Using existing cryptography techniques, that data can even be processed without ever being decrypted, ensuring the highest level of security.

    About the Author/ Ameesh Divatia

    Ameesh Divatia is CEO and Co-Founder of Baffle, developer of the world’s first solution for end-to-end database encryption. Ameesh is a serial entrepreneur with a track record of converting innovative ideas into successful businesses. Connect with him on LinkedIn.

  • Improve IT Security by Improving Company Culture

    Improve IT Security by Improving Company Culture

    All around the world, cybercrime rates are rising, and it’s clear that traditional criminals are constantly developing new ways to attack. These days, wreaking havoc requires nothing more than internet connectivity and a pronounced lack of scruples. With a lowering barrier for entry causing an increase in the pool of malicious actors, many enterprises are struggling to protect themselves.

    Buzzwords such as “cybercrime” and “black hat” are now commonplace, and global spending to combat cybercrime reached $80 billion in 2016. Despite these efforts, only 38 percent of organizations surveyed for ISACA’s “2015 Global Cybersecurity Status Report” were confident in their ability to defend against cybercrime attacks.

    Why Does Security Still Suck?

    With high levels of cybercrime awareness and direct steps being taken to address these challenges, it begs the question: Why does IT security still suck?

    One of the primary reasons many enterprises struggle with cybersecurity is a lack of cultural support in the workplace. C-suite policies often hinder success more than they help by pushing employees to the brink and creating an environment that leaves their businesses susceptible to human error and attacks.

    While Brooks’ Law can serve well as a guide, it’s often a harbinger of bigger problems in many enterprises: When a software project is running late, leadership often brings another employee onto the project and, as a result, slows things down even more. Between the security system add-ons and services and the human capital involved in taking time to understand the issues as they arise, productivity takes a major blow—without any measurable benefit to security. This traditional tactic has attempted to ignore the crucial fact that 77 percent of professionals said that their information security policies and teams are slowing IT down.

    Compounding these issues is the fact that traditional security tools require an immense amount of time and manual labor. Because these legacy platforms do not have the ability to automate even basic functions, IT professionals are often required to monitor security tasks and patch vulnerabilities around the clock. This is a major responsibility, as the costs of an attack or other breach can be devastating to an enterprise.

    Further, IT security professionals are rarely rewarded for successful efforts. This is challenging for two reasons. First, no one is congratulated for creating a security-sound app, as the consumer expects nothing less. Second, it can be difficult to convince corporate leadership of the need for improved, automated security tools before an attack occurs. Painting a realistic depiction of a hypothetical situation (in this case, the damage caused by a cyberattack) is hard to do, and professionals often struggle to demonstrate their value without resorting to scare tactics. Scare tactics, independent of statistical supportability, have a shelf life and are subject to diminishing returns. Corporate leadership teams don’t regularly identify or prioritize security problems until it’s too late, so they don’t consider the cost to their employees who are fighting these battles on a daily basis. Together, all of these factors add up to fatigue, frustration and burnout for IT security professionals.

    It’s safe to assume that we all want to do our best work. When we don’t have the tools and support necessary to do quality work, attitudes and culture suffer.

    To stay ahead of security concerns, C-suite policies must not tackle IT issues or adjust to new regulations as they arise, but ensure that efficient, effective security practices are baked into agile DevOps processes rather than bolted on. It is essential for leadership to be proactive, rather than reactive—once an enterprise falls behind the curve, its software applications and valuable data are at increased risk until vulnerabilities can be patched.

    Perhaps not surprisingly, this proactive attitude does not always come naturally. Management often wants to do things the way they’ve always been done, but they need to become more agile as well. Security within an organization will benefit from pushing awareness across the enterprise, rather than keeping security professionals siloed within their own department. There’s a fine line between educating employees and using scare tactics, but leadership must be informed of vulnerabilities and necessary steps for shoring up weaknesses.

    However, education can only go so far; automation is the real key to taking the risk out of the hands of security professionals. Modern tools will allow your team to rest easy at night while proactively focusing on your enterprise’s rapidly evolving applications. This makes your employees happier, your security stronger and your business better.

    About the Author / Ash Wilson

    Ash Wilson is a strategic engineering specialist at CloudPassage. He has been a paid tech worker since March 2000, and a hobbyist long before that. He came to security via network engineering and systems administration. Ash spent the last five years in post-sales engineering and strategic engineering for security product companies. Connect with him on LinkedIn and Twitter.

  • Signal Sciences Looks to DevSecOps to Improve App Security

    Signal Sciences Looks to DevSecOps to Improve App Security

    The time has come to put control over IT security into the hands of the developers who increasingly are being held accountable for it. To make that possible, Signal Sciences has launched a Web Protection Platform (WPP) capable of inspecting traffic in real time across multiple deployment models.

    Intended as a replacement for more traditional web applications firewalls (WAF), WPP redirects any suspicious traffic to a cloud analytics engine without adding any meaningful overhead in terms of overall latency, says Signal Sciences CEO Andrew Peterson.

    What makes WPP unique, he notes, is that it can be deployed in three different modes. When deployed on a local server, no changes to the application code are required. WPP also can be deployed as a reverse proxy in from of a web server. But from a DevSecOps perspective, the most flexible options is to deploy WPP in a runtime application self protection (RASP) mode that allows developers to embed WPP directly into their source code. In the later instance, Peterson says developers can assume security responsibility for their own applications, in keeping with process employed by organizations that have implemented advanced DevOps processes.

    Peterson says WPP not only provides protection against the top 10 most common web applications threats, but it also thwarts distributed denial of service (DDoS) attacks, account takeover and even attacks employing malware embedded in custom business logic.

    Regardless of the delivery model, Peterson says it’s become apparent that legacy WAF are not able to secure modern applications based on containers and microservices, Embedding WPP in application source code enables developers to embed a cybersecurity defense mechanism in each container-based microservice in a way that scales over time.

    As part of its commitment to DevSecOps, Signal Sciences has created 16 pre-built integrations with a range of third-party DevOps tools and security technologies, including Atlassian JIRA software, Datadog, PagerDuty, Slack and Splunk. In addition, DevOps teams can take advantage of an application programming interface (API) that Signal Sciences has developed to integrate WPP with other applications.

    Of course, the whole DevSecOps movement is only in its infancy. Most IT organizations are still struggling with the concept. It’s also not clear how much IT security professionals will be comfortable relinquishing control over application security to developers. However, Signal Sciences claims that 95 percent of its customers have implemented automated blocking, versus only 10 percent to 15 percent of IT organizations that have implemented a WAF.

    Signal Sciences is betting that in much the same way they now exercise more influence over IT operation, developers will play a much larger role in IT security. In fact, as developers are held more accountable for application security, Peterson says many of them will demand to be able to programmatically implement IT security controls. Naturally, there’s no such thing as perfect security. But is the case of application security, DevSecOps may turn out to be our only hope.

    — Mike Vizard

  • From Architect to Operator: The Rise of Developers

    From Architect to Operator: The Rise of Developers

     Over the past five years, DevOps has transformed from a model for agile software development practices to the aspirational standard for functions across the IT spectrum. Previously, developers and IT Ops teams were distinct and siloed—developers built the application and IT Ops managed production environments—but now many in the industry have shifted to create a net-new liaison between the two, allowing applications to exist simultaneously in the worlds of development and production.

    While everyone is focusing on the convergence and collaboration of the developer and the IT Ops person, however, the storyline is changing again. The focus is now shifting back to the developer (and his/her specific skill sets), as there’s an increased demand for a single team to manage the entire application life cycle. Now more than ever, the people who actually develop the systems are poised to take ownership of traditional IT operations functions, such as maintenance, performance and availability.

    As IT continues to evolve, three trends point to the expanding and evolving role of the developer.

    1. The decoupling of infrastructure from services. With the rise of public and private clouds, more of the technology stack is becoming abstracted away from infrastructure, and often offloaded to a provider. This has created challenges for how developers manage and deliver applications in this new environment. In the past, IT operations was responsible for ensuring things such as availability and performance, but now, developers can build those capabilities into the applications themselves.
    2. The elimination of infrastructure setup. IT Ops roles have traditionally been the gatekeepers, and new technologies didn’t make their way into the data center if it didn’t pass their standards. Getting into the data center was just the first step, though, as lengthy deployment of physical infrastructure and provisioning of virtualized instances for applications would require substantial expertise and time. Now, developers can spin up services instantaneously, and infrastructure setup has been reduced to a simple configuration file. It is the developer who understands which resources the application will need, and with infrastructure reduced to a couple lines of code, the speed at which it can be applied is impossible to ignore.
    3. Microservices create fault tolerance. How we’re building applications also greatly impact how they will run in the future. Historically, you would build a single monolithic service that would respond to every request from the users of that application. This approach meant that when a part of the service failed, everything would go down. However, when you abstract away the infrastructure, you gain the ability to decentralize the application or service into many loosely coupled microservices. This makes the application much more fault-tolerant and reduces the impact of an outage or shortage of resources. As such, developers can help ensure system continuity and performance by building resilience and monitoring capabilities into the software.

    End-to-End Visibility and the Need for IT Ops Persists

    While developers are certainly on the rise, the role of IT Ops remains uniquely necessary in today’s IT environment. IT Ops will always have the best end-to-end IT system perspective, encompassing the application environment as well as shared services and infrastructure (think backup, endpoint protection, single sign-on, DNS, etc).

    Developers build visibility from the inside out. But because it’s happening in the app itself, there’s no outside-in look, and thus pieces of the stack go unmonitored. As a result, you can’t understand the holistic end-user experience—which, when it comes to application health, is both the start of the conversation and the end of the argument. IT Ops brings incredible value, offering end-to-end visibility with better monitoring and a focus on ensuring every transaction—both internal and external—goes smoothly. While it has become common for developers to instrument their applications, they don’t have nearly as much expertise in end-to-end service management and measuring performance across each component. Additionally, IT Ops workers tend to possess a great level of operational rigor; they’re better versed in dealing with third-party vendors; and they understand the entire system (the weakest link, what works, what fails, etc.), including back-end functions, in a way that developers simply don’t.

    What Comes Next for Developers?

    We’re already seeing how developers are taking greater control over traditional IT operations functions, but what comes next? Looking forward a few years, I believe the next frontier to monitor is the role developers will play in SecOps. Security attacks are about finding the path of least resistance, and as SecOps matures into active threat-hunting and breach detection, attackers will evolve their methods. If SecOps can solve current attack vectors—phishing, especially—tricking software into following unexpected code paths will once again be a reasonable route to a breach.

    But there are ways to mitigate that during the development process, by building security into the code itself. As SecOps teams increasingly treat the environment as an ecosystem, they’ll see the application itself as a vulnerable piece of the attack surface; they may begin requiring secure development practices with a level of governance over development teams. As security increasingly becomes everyone’s job, everyone in IT must shift their mindset, and while development teams may be late to the party, SecOps will eventually extend a mandatory invitation.

    About the Author / Eric Thomas

    Eric Thomas serves as Director of Solutions Architecture for IT analytics company ExtraHop. Eric leads the Professional Services team, and draws on over 20 years of experience in IT operations. Before joining ExtraHop, Eric performed a variety of operational roles, most recently as Director of Advanced Engineering for Thomson Reuters, where he led a team of performance and availability specialists, supporting over 200 applications representing $2B in annual revenue. His prior experience includes Enterprise IT management, SaaS production operations and next-generation technology advocacy.

     

  • Meeting the Need for Speed in Cyber Threat Response

    Meeting the Need for Speed in Cyber Threat Response

    In the very early days of the internet, hackers most likely were “lone wolves.” They might be an unhappy customer, a disgruntled employee or a tech-savvy youth who just wanted to see if he could breach a target’s defenses.

    Occasionally, hackers might aspire to more devious crimes including identity theft, blackmail, theft of trade secrets, exposure of personal information or monetary theft. These types of hackers were annoying, unnerving and potentially dangerous, but they seldom caused widespread damages or serious financial losses. Today, however, cybersecurity professionals face an entirely new group of hackers and an escalating number of attacks—and security strategies and tools have not been able to keep pace.

    The Modern Hackers

    The greatest source of risk comes from well-financed, sophisticated hackers who often are connected to a government that sanctions and supports their activities. These groups constantly refine their already impressive skills and they are patient as well as persistent. They know how to circumvent defenses that rely on signatures or pattern matching, and they are adept at launching attacks that may take months to achieve fruition.

    For example, sophisticated hackers may launch an upstream attack aimed at companies that make the products that others use for security, including SSL certificates and other digital credentials. These credentials are then used to steal money, intellectual data or other information from the group’s real targets. Hackers can also attack in stages, such as first going after information that will give them access to an organization’s network, allowing them to conduct whatever mayhem they want on their own schedule. They may install an encrypted “zero day” attack, for instance, or simply wait until a desirable piece of intellectual property is completed.

    Why Speedy Responses Are Essential

    The longer that a breach goes undetected, the more damage the incident will cause. It is a bit like having an undetected roof leak; the longer the leak allows water to penetrate beneath the roof, the more damage the water will do to the structure.

    Unfortunately, most organizations are not doing a very good job of detecting breaches quickly. In 2014, the Verizon Data Breach Investigations Report revealed that 43 percent of all web application attacks were not discovered for months, and 85 percent of the point-of-sale intrusions went undetected for weeks. Other breaches have gone without detection for years, such as the Excellus breach that lasted 18 months and the allegedly state-sponsored “Project Sauron” attack that was in operation for almost five years.

    When attackers have months or years to access a victim’s network, they have ample opportunity and time to inflict a substantial amount of damage. They can even expand their attack to infiltrate the networks of the original target’s customers or vendors. Interestingly, a study conducted by the Ponemon Institute found that approximately 33 percent of all attacks were not detected for two years — and two-thirds of the attacks were discovered by a third party rather than the compromised organization.

    However, a report issued in June 2016 by the Business Continuity Institute indicates that many organizations are making progress when it comes to responding to cyberattacks. BCI surveyed 369 organizations in 61 countries. Approximately 66 percent reported that they had suffered at least one attack during the previous 12 months, and 15 percent reported that they had suffered 10 or more attacks. Roughly 31 percent claimed that they responded to attacks within an hour, but 19 percent said that they took at least four hours to respond. Approximately 24 percent were hit by a denial-of-service attack, while 45 percent suffered a malware attack; both forms of attack rendered the organization’s network inoperable or contaminated.

    Responding Quickly to Attacks

    Although most cybersecurity professionals know that response time is critical, not all of them understand the best ways to ensure that the speed is there when needed.

    • A speedy response starts with an effective incident response plan. The plan should be based on a thorough assessment of threats, risks and potential failure modes, and it should be updated frequently and available to all parties.
    • “Practice makes perfect.” Response teams should have ample opportunities to practice their tasks through frequent “dry runs.” Instead of wasting time trying to determine what they should do when an attack does happen, they can react reflexively.
    • Automation can greatly reduce the amount of time required to respond to an incident. For example, without automation, if a breach occurs, staff members might have to manually check 5,000 or more endpoints. However, an automation platform can collect, analyze and report on the activity in much less time.
    • Increase visibility across the different domains and systems. A recent survey of IT remediation teams conducted by the SANS Institute revealed that almost half felt that the lack of visibility was their main impediment to an effective, speedy response. Using a security information and event management (SIEM) solution for log aggregation and correlation can increase visibility across organization.

    When the health of your organization is at risk, taking even an hour to respond to an incident can be far too long. Taking a day, a week or a month to detect and respond to a threat can do irreparable damage. With steps in place, organizations can meet their need for speed in addressing cyber threats quickly, to best protect their networks.

    About the Author / Rishi Bhargava

    Rishi Bhargava is co-founder and VP of Marketing for Demisto, a cyber security startup with the mission to make security operations “faster, leaner and smarter.” Prior to founding Demisto, he was vice president and general manager of the Software Defined Datacenter Group at Intel Security, and before Intel, he was vice president of product management for Datacenter and Server security products at McAfee, now part of Intel Security. He has more than a dozen patents in the area of computer security. He holds a BS in Computer Science from Indian Institute of Technology, New Delhi, and a Masters in Computer Science from University of Southern California, Los Angeles.

  • When Did Safety Nets Become Optional?

    When Did Safety Nets Become Optional?

    There are various reasons why some organizations would not be interested in protecting their data. These reasons could range from the lack of financial resources to the lack of non-financial resources, such as engineers to implement a solution. Regardless of whether there is a good reason to not protect your data, the net result is the same: If organizations don’t do it and something bad happens, they will be in a world of hurt.

    Data is the lifeblood of any business. It’s true that not all data is created equal, so some organizations may be comfortable losing some data. And it’s also true that there are some systems or applications that are built to not only tolerate data loss, but also seamlessly absorb the loss of data. The reality is that this is not 100 percent of the systems in your business, nor is it 100 percent of the data. If you were to completely lose the users table in your application or have it suffer from data corruption, how would you explain this situation to your customers? Can you realistically tell them that the money wasn’t there, or you didn’t have the resources to protect their data and yours? What type of trust would that instill in them for you as a provider of services? What type of trust would that instill in the business for your technology team?

    For most businesses, data protection should be thought of as a component of the overall security strategy. If you wouldn’t set up a network infrastructure without a firewall for protection, why would you create an application without protecting the data that powers it?

    Unfortunately, some form of system failure is inevitable. There will come a time when something bad happens. The best thing you can do is to be prepared as possible. Providing yourself with a safety net when this happens is doable, but shouldn’t be thought of as optional. There are some basics tenets that should be involved in providing a proper safety net. The most important of them is to plan for and failure and test your recovery procedures. This team education is your primary line of defense against disaster. It will help mitigate many of the potential failure scenarios through awareness. Data protection is for what happens when things get past this point. And protecting data should not be optional.

    — Jeannie Liou

  • DevOps and Database Security

    DevOps and Database Security

    Osterman Research recently released a survey-based report on database security. The results don’t exactly instill confidence where username breaches are concerned: While more than 50 percent of respondents felt that a breach of the database would be a serious problem for their organization, 44 percent responded that it would take more than a day to detect compromised credentials and a breach of data. Considering that attackers are going to get in and get out as fast as possible, more than 24 hours is plenty of time for those compromised credentials to result in copies of tables making their way to the dark web. Some of our biggest hacks—Yahoo! springs to mind—take much, much longer to be detected.

    There are tools available to monitor database logins and activity, from free (and sometimes onerous) logging for databases including MariaDB, MongoDB and MySQL to review and analysis through things such as Splunk plugins for most database systems. Once you are tracking logins and source IPs and possibly watching for spikes in query volumes, the power of DevOps can help you manage monitoring.

    The key here is to collect the data, even if temporarily. A great first step is building a process that turns on login-attempt logging for a set period of time, then processes the resulting file to send the user a list of when they logged in and from where.

    Next, capture summary information about number of queries and response sizes. That can show abuse of credentials, by either internal or external bad actors. The issue is not the availability of tools to do these jobs; the issue is making it a priority.

    While not exposing your database to the internet is a good policy, monitoring database credentials provides in-depth defense against external attackers and a defense against internal attackers. Utilizing the tools available plus some work from DevOps (to automate the process, then to work out a way to add new application and user logins to the monitoring system) will improve your ability to detect credential issues, and the process—as so often happens when DevOps is involved—will force you to review which applications are hitting the database from where, possibly opening eyes to ideas for improvement in database usage and location.

    These are the areas of security where DevOps really can help; it is rare for any one team to control security for logins/queries on the database. Is it the DBA’s responsibility? The security team? Operations (which generally creates the accounts)? Utilizing the tools available, and sitting down to discuss which makes the most sense for your organization, you can generate a simple report to be reviewed on a regular basis and settle the responsibility question. That means there is no huge loss of time pawing through logs and no waiting weeks to find out your database has been exfiltrated. It just makes sense, and it bridges the gap where security gets direct benefit out of DevOps, instead of the indirect benefit offered by standardized processes.

    — Don Macvittie

  • Veracode Makes DevSecOps Transition Easier for Developers

    Veracode Makes DevSecOps Transition Easier for Developers

    Following the formal acquisition of Veracode by CA Technologies, a much bigger effort to make security a more integrated element of DevOps has kicked off in earnest.

    Veracode recently unfurled an update to its application security platform aimed specifically at developers that provides security findings as each application module is scanned. Tim Jarrett, senior director of enterprise security strategy for Veracode, says the idea is to provide developers with that information from static analysis delivered via the Veracode platform as early in the application development lifecycle process as possible.

    Other new capabilities include support for custom cleansing functions to automate remediating issues involving common known vulnerabilities and an auto-scan capability that gets implemented any time a file is saved.

    Also with this release, Veracode is adding support for the Perl programming language that is still widely used for building web applications.

    Jarrett notes that organizations these days are holding developers more accountable for security issues that are easier to fix during the application development process. Addressing those same issues after an application is deployed in production not only exposes organizations to security threats, but can be much more expensive to fix.

    The challenge is that most organizations have yet to solve the riddle for getting developers to address security issues earlier in the application development cycle. Jarrett says far too many developers are conditioned to view IT security has being someone else’s job inside the organization. Veracode is trying to make it simple to address security issues using tools that make the process as frictionless as, say, relying on a spell checker to publish a higher-quality document.

    Obviously, there will never be perfect security. But far too many of the issues that IT security teams regularly deal with relate to known exploits. At a time when cybercriminals are making use of a variety of automated tools to discover those exploits, most IT security teams are outgunned. Worse yet, many IT organizations can’t even find qualified cybersecurity professionals to hire in the first place.

    On the plus side, however, as DevOps processes mature, many developers are now assuming complete responsibility for the maintenance of the code they write, including all security issues. This not only leads to higher-quality applications, it also results in those developers being more vigilant when it comes to address security issues they would otherwise need to address themselves once an application is deployed in production. In some quarters, this earlier focus on security in the application development and deployment process is referred to as DevSecOps. As a discipline within most IT organizations, however, DevSecOps remains relatively nascent.

    Of course, regulatory bodies are increasingly treating organizations that fall prey to security attacks less like victims. Instead, they are holding them accountable for ignoring best security practices by assessing fines for losing control over sensitive data. As those fines increase the blame for incurring those fines eventually cascades back to the developer. Given that changing climate, it might not be too long before developers recognize that embracing DevSecOps is in their own best interests.

    — Mike Vizard

  • DevSecOps @RSAC, My 2 Favorite Presentations

    DevSecOps @RSAC, My 2 Favorite Presentations

    For the third year, devopsy.kinsta.cloud hosted a DevSecOps/Rugged DevOps event at RSA Conference. As with years before,  we smashed attendance records. We had just shy of 900 people stop in on Monday of RSA Week to hear from the 11 presentations we hosted. Taken in total, the presentations presented a wide range of DevSecOps issues. I wanted to draw your attention, though, to two of the presentations that I really enjoyed.

    First of my favorite presentations

    The first was from someone I had not met before who came to our attention via our call for speakers. Duane Schleen presented, “Implementing DevOps in a Regulated Environment: The Aetna Experience.” His presentation is below:

    Why did I love this presentation? Good question. First of all it is rare that we get such an open peak behind the kimono at the actual inner workings of an enterprise, especially in such a regulated industry as insurance.

    More than that though I am telling you that Duane Schleen or DJ as he is called is going to be a DevSecOps rock star. Can’t wait for him to write a few articles for us here at devopsy.kinsta.cloud. If you get a chance to see him speak at a conference near you, jump at it. Can you tell I am a fan?

    On top of this the look Schleen gives us into DevSecOps at Aetna shows that despite the naysayers, you can go faster, with higher quality and be more secure!

    The Second Presentation I loved

    The second presentation I wanted to bring to your attention was the opening keynote by John Willis. Most of you have probably seen John present before either live (if you are lucky) or on line. John is of course a co-author of the DevOps Handbook as well.

    John’s presentation is entitled, “Breaking Bad Equilibrium”.  It is about cooperation in DevOps, technical debt and uses some game theory to explain some of the John’s thoughts.

    My favorite part is when John uses some clips from the UK game show “Golden Ball” to discuss Nash Equilibrium (or prisoners dilemma )  and game theory. Both clips really grab you and make you think (as many of John’s presentations do). I will let his presentation speak for itself though.

    Beyond, these two excellent presentations, you can see the rest of the presentations from our DevSecOps event at RSA Conference this year on our DevOpsTV channel on YouTube. The link takes you to the playlist with all 11 presentations.

    This years DevSecOps event at RSAC was a smashing success with almost 900 people stoping in to hear some of the excellent presentations. It did this authors heart good to see this great mixing of the DevOps and security tribes coming together.

    — Alan Shimel

  • Securing Immutable Servers in a Serverless World

    Securing Immutable Servers in a Serverless World

    Snowflakes are beautiful, unique creations. But, let’s keep them in nature. They don’t belong in our server infrastructure. Snowflake servers, where every configuration is just a little different, can introduce unnecessary security vulnerabilities and complications. While common in IT infrastructure, in the DevOps realm, they are gradually becoming ancient history.

    At the recent All Day DevOps conference, Erlend Oftedal (@webtonull), with Blank and head of the OWASP Norway chapter, discussed the benefits of immutable infrastructure practices within serverless architectures. Erland walked us through the positive effects on security as well as offered insight on potential problems.

    Erlend outlined the progress from physical servers to immutable servers, discussing the benefits of each step and the concerns that lead to the next phase, ending with immutable servers—that is, they can’t be changed. Once set up, they are set. Automated processes coupled with immutability principles can eliminate snowflake servers.

    Immutability isn’t a new concept. Some classic examples include: live Linux CDs, internet cafes, schools, libraries, hotel business centers, etc. To set up immutable servers, Erlend outlines these steps:

    1. Find a suitable base image
    2. Build a specific image for the application (dependencies, application, secrets)
    3. Deploy image to server(s)
    4. Repeat steps 2-3 for new versions.

    Of course, this immediately raises questions.

    What about data? He notes that, because data inherently changes, data has to be stored externally.

    How do you deploy changes? Well, you don’t change the server. You take one out and put a new one in. If that one fails, roll back to the previous one.

    How do you manage secrets? You can build secrets in, leverage cloud key management or use third-party services.

    How do we apply security patches? If truly immutable, you deploy a new server with the patch. However, you can have a semi-immutable server that allows for automatically installing patches but still doesn’t allow for logins or manual changes.

    Speaking of security, what are the security advantages? For starters, if an attacker is in your server, it will be thrown out when you change servers, although it may come back if the vulnerability isn’t patched. It also allows for very specialized images by removing all unneeded packages. With these specialized images, you can more easily audit and monitor the system for unexpected file changes, logins and connections.

    Erlend discussed containers because they are a step closer to a serverless world. Containers isolate processes and all run on the same OS. Of course, you can make them immutable, but, whether they are or not, there are some key security best practices you’ll want to consider:

    • Don’t run as root inside container
    • Implement user namespaces so the root account within the container is separated from the root account outside the container
    • Utilize the least privileges necessary for capabilities and resources
    • Keep them up to date
    • Automate scanning using tools such as Sonatype Nexus, Twistlock, Clair or Aqua.
    • Separate untrusted and trusted containers

    Erlend also dove into serverless architecture. While there is debate over what exactly qualifies as serverless, there are five principles that Erlend highlighted:

    • Use a compute service to execute code on demand
    • Write single-purpose, stateless functions
    • Design push-based, event-driven pipelines
    • Create thicker, more powerful front ends
    • Embrace third-party services

    Migrating to immutable, serverless infrastructure is a topic to be discussed well beyond this blog post and even Erlend’s session. Whatever you do in the future, though, take his parting words to heart: “The cloud can solve many of your problems, but in the end you cannot transfer your responsibility for security.”

    Erlend’s session was packed with information. If this piqued your interest, you should watch his complete session in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free of charge here.

    — Derek E. Weeks