devopsy.kinsta.cloud

Category: DevSecOps

  • Are Your Web Applications Prepared for the Holidays?

    Are Your Web Applications Prepared for the Holidays?

    Three best practices to secure your website for the coming retail boom 

    The holidays are upon us, which means retailers are racing to launch new promotions, sales and other temporary web pages in time for what is anticipated to be a record-breaking retail season. Amidst their haste to prepare, some businesses forget—or don’t realize—that there are often a number of critical vulnerabilities in their web applications and servers that go completely unnoticed or unaddressed. In fact, recent research has shown that retail has one of the worst records when it comes to applications failing security checks. This is because web applications are often created quickly, without security in mind. Or even worse, they are created, launched and then forgotten. And if there is one thing we know about applications—they age like milk, not wine.

    Our research shows that the average web application contains 11 vulnerabilities, with an average of seven critical vulnerabilities. And every one of those vulnerabilities is a chance for a criminal to breach your company. The last thing a retailer needs right before the holidays is to become yet another victim of cyberattack and negative headline.

    Security for Web Applications

    To sail smoothly through the holidays, here are three basic hygiene principles that can be used to ensure your business’ web apps are thoroughly safeguarded:

    Test Early, Scan Often

    The importance of scanning website applications regularly is critical to ensuring web applications aren’t launched with known vulnerabilities. According to CA Veracode’s State of Software Security Report, 60 percent of web applications are scanned less than four times a year, 36 percent of organizations don’t run any kind of static analysis security testing (SAST) and 48 percent of organizations aren’t running any kind of dynamic analysis security testing (DAST). Part of the problem is that so many web servers have vulnerabilities that have not been patched, with 25 percent of those scanned possessing a high or very high severity vulnerability—meaning they could be easily exploited by attackers to compromise websites and potentially steal or compromise consumer data.

    Best practice for IT departments is to make sure their web servers are not sending out information that could be valuable to an attacker, such as server version information, for example.

    Discovery scans of websites show that organizations have 30 percent to 40 percent more websites than they thought they had. This could include marketing pop-up sites that are left online and forgotten about. These sites often are left online with a redirect instead of being taken down—this is a “messy” practice that can create entry portals for hackers later on.

    Shockingly, applications are only scanned twice a year on average. But scanning more frequently during development allows developers to fix on average 48 percent more vulnerabilities versus conducting scans that only give applications an up-or-down on security policy.

    Prioritize Remediation Based on Risk

    Testing and scanning for vulnerabilities is only half the battle—businesses need to fix the flaws they find. Out of 400,000 application scans that took place over the course of a year, only 18 percent of flaws were closed in less than 30 days, while 49 percent of flaws fixed took more than 90 days to close. Because critical vulnerabilities put your organization at the most risk, companies should fix the most severe vulnerabilities first. Many organizations are wisely doing this already—data shows organizations fix high severity vulnerabilities at twice the overall fix rate.

    To prioritize risk, organizations must account for the severity of the flaw in addition to the business value of the application at risk. In addition, not all high-severity flaws are weighted equally—some organizations may choose to prioritize more high- and medium-level vulnerabilities that have more value, or are in more sensitive applications, over very high severity vulnerabilities in less sensitive applications.

    Empower Developers with Resources to Make Security Part of Their Process

    It’s important that cybersecurity professionals nurture their relationships with the people who are closest to the development process. But this is often deprioritized. According to findings from a survey conducted by CA Veracode and ESG, only 18 percent of development team leaders said security was the most important metric for measuring their team’s performance. And security education and ongoing training is equally neglected, with 68 percent of surveyed developers and IT pros saying their organizations aren’t supplying them with adequate training. This endemic goes all the way back to college—76 percent of respondents reported that they weren’t required to complete any security courses while in school.

    However, developers do care about security, and these stats should serve as a reminder to maintain vigilance in helping developers get the tools and reinforcement they need to fix vulnerabilities efficiently.  In fact, there is a 19 percent improvement in vulnerability fix rates when employers provide developers with on-demand training courses.

    As more cybersecurity threats continue to emerge, having a “clean” app landscape has unmatched long-term benefits and can help ensure customers continue to have trust in your brands.

    About the Author / Joe Pelletier

    Joe Pelletier is the Director of Product Management for Veracode’s Web Application Security and Runtime Protection product lines. He has worked in application security for over six years, originally helping large enterprise clients implement secure development practices and programs. Joe is a hands-on learner and passionate about building great products and teams. Prior to Veracode, Joe worked in the financial services industry and helped develop portfolio management and investment research platforms. He received his degree in Finance from Bryant University. Follow Joe on Twitter.

  • Moving Security Beyond SSH and PKI

    Moving Security Beyond SSH and PKI

    SSH (secure shell) is still the most common method of remotely accessing a Linux server, which makes it a common target for attackers attempting to infiltrate corporate networks. While the protocol itself carries a number of advanced security properties, it does allow for human error, opening the door for unwarranted privileged access to sensitive company resources.

    Keeping track of all valid credentials across a company is something that IT departments continually struggle with. The stakes are high if they fall into the wrong hands, essentially handing over the proverbial “keys to the kingdom.” A recent study by Dimensional Research found that 90 percent of respondents do not have a complete and accurate inventory of all SSH keys, and 63 percent don’t actively rotate keys, even when an administrator leaves the company.

    Managing privileged access to servers has always been a rigorous exercise in key management. There are a number of best practices to follow to avoid the many common pitfalls, such as storing private keys in a vault service or maintaining a strict rotation policy, but they don’t get to the crux of the matter: The credentials are static. Here’s a (not so) crazy thought: What if we got rid of them entirely? Static credentials are a thing of the past, representing the failed perimeter model of corporate security.

    Problems with Traditional PKI

    The traditional PKI (public key infrastructure) that backs SSH was built for a different time, when a key exchange meant enough to grant trust. Without a proper authentication process, there is no clear way to attribute to a person, nor a feasible way to provide any historical context. As these keys get issued and distributed across fleets of infrastructure and cloud services, the challenge only compounds. Each public key accrues more privileges over time; the longer it’s been alive, the more likely it’s been shared with a resource, making it extremely difficult to track and subsequently revoke. With this model, time is a bug that can’t be fixed.

    Authorizing a specific request should also go beyond the mere presence of the public key within the authorized_keys file of the server. Independent of authentication, authorization is about who should and should not be able to access a specific server from a known device, and what permissions they have on the machine. You may have a policy that states only members of the engineering team can only access a production server through a bastion host. Adhering to that policy in practice, however, is impossible without a proper authorization process.

    Enter Zero Trust Security

    We’ve come to a consensus across the industry that the network perimeter is breaking down in the modern cloud era. It’s time to take that one step further and agree on a new model of trust attestation to match, where decisions are removed from the network layer and handled correctly at the application layer. Flipping the model around like this means starting with zero privileges by default, and only granting access to a resource once a request has been fully authenticated and authorized. Verify, then trust—the mantra of Zero Trust.

    Google’s BeyondCorp is the marquee example of Zero Trust done right, an internal initiative meant to better secure how employees access corporate resources. The end result is a carefully crafted distributed system that makes real-time trust decisions based on what is known about a user and their device, allowing the thousands of Googlers across the globe to work securely from any location without the use of a VPN. BeyondCorp is just one example, and we’ve seen more and more companies start to adopt a similar approach.

    Ephemeral Client Certificates

    The thinking behind ephemeral credentials is that a request triggers independent authentication and authorization processes, where a trust attestation is made against the policies of the resource. If valid, a single use credential is issued, which is used to initiate a secure session with the resource. This credential is tightly scoped to the specific request, rendered useless in any other scenario.

    The fundamentals of this workflow can be accomplished through a client certificate-backed PKI architecture. Client certificates became a supported feature of OpenSSH in 2011 with the introduction of version 5.4. Unlike standard SSH keys, which carry no metadata, certificates are cryptographically verifiable metadata objects that can inject information such as usernames, roles and more. Time now becomes a feature because the scope of the credential truly represents a dynamic attestation of trust.

    The fine-grained access controls inherent in a client certificate-backed PKI architecture solves for the problems with SSH keys because the credential can be tied to an actual user. The threat vector of lost, stolen or misused credentials is also eliminated, saving managers from the numerous headaches associated with SSH key management.

    To put these ephemeral credentials into action, you need to surround the client-certificate PKI with the supporting access controls. Companies with the means can build their own system similar to Google’s BeyondCorp, but this is no simple task, as you need to operate your own Certificate Authority along with a distributed system capable of performing dynamic authentication and authorization against policies in real time.

    About the Author / Ivan Dwyer

    Ivan Dwyer is the VP of Product Marketing at ScaleFT, working with the community to raise awareness around BeyondCorp and Zero Trust for organizations of all kinds looking to modernize their security architecture. Connect with him on LinkedIn and follow him on Twitter.

  • Trend Micro Expands DevSecOps Portfolio

    Trend Micro Expands DevSecOps Portfolio

    At the AWS re:Invent 2017 conference today, Trend Micro significantly expanded its reach into DevSecOps by announcing it has acquired Immunio, a provider of agent software that can be employed on a central platform engine to execute security policies on a granular level.

    In addition, Trend Micro announced it is adding support for container image scanning to its portfolio of security products as well by the spring of 2018.

    Mark Nunnikhoven, vice president of cloud research for Trend Micro, says both the Immunio policy engine and the container image scanning technology are now part of the Trend Micro Hybrid Cloud Security family of offerings that the company plans to expand for developers. Those capabilities, in turn, are exposed to developers deploying applications on-premises or in a public cloud primarily through its Trend Micro Deep Security cloud service, a suite of security technologies and threat detection services exposed by application programming interfaces (APIs).

    Nunnikhoven notes Trend Micro has seen a significant increase over the last several years in the use of programmatic approaches to managing security. Most of the shift has been driven by developers who have driven security to the left as part of the rise of DevSecOps. But he says security professionals are also starting to develop programming skills to advance IT security both in the cloud and on-premises.

    Nunnikhoven says the rise of containers is making DevSecOps more challenging. Too many developers are still grabbing containers from registries without checking them for vulnerabilities. As many as one-third of containers may contain known vulnerabilities, he says. To address that issue, Gartner estimates that by 2019 more than 70 percent of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open-source components and commercial packages. That compares to less than 10 percent in 2016.

    IT organizations, however, don’t just want to be able to scan container images. Nunnikhoven says it’s clear they want a set of integrated security tools that can be employed to secure both the containers and the hosts they are deployed on. In the case of Immunio, Trend Micro is adding a security technology that can be embedded in applications running on virtual machines or bare-metal servers, as well as containers making up a microservice.

    While Trend Micro has a long history of providing security products to IT and cybersecurity professionals, it and virtually every other security vendor are competing against a host of startups that have embraced DevSecOps to change how security technologies are consumed. In its effort to remain relevant, Trend Micro is expanding its portfolio of products to focus more on developers. Over time, however, Nunnikhoven expects there will be increased collaboration between developers and IT security professionals, as the lines of responsibility for various aspects of security are better drawn.

    In the meantime, however, Trend Micro—like most of the vendors in the IT security industry—is now clearly making a hard shift to the DevOps left.

    — Mike Vizard

  • Barracuda Networks Advances DevSecOps Agenda

    Barracuda Networks Advances DevSecOps Agenda

    Thanks to the rise of DevOps, a fundamental shift is now underway in terms of the amount of influence developers exercise across the enterprise. Rather than simply dumping code on IT operations teams, developers increasingly are being held accountable for applications end to end. As such, developers now often exercise a lot more influence over which software-defined infrastructure and security platforms will be employed as part of what is referred to as the “shift to the left.” These platforms all have in common a well-defined set of application programming interfaces (APIs) that makes them accessible to developers.

    Against that backdrop, Barracuda Networks announced its Barracuda NextGen Firewall can be configured via the IT automation framework developed by Puppet Labs. Previously, only the company’s Web Application Firewall was integrated with the Puppet framework.

    In addition, the Barracuda NextGen Firewall is now available as a metered billing service in the Amazon Web Services (AWS) Marketplace. That marks the company’s second metered billing service on AWS, after making a similar move with the Barracuda Web Application Firewall last year.

    Tim Jefferson, vice president of public cloud, says an increased focus on application security is driving an expansion of DevOps processes to now include DevSecOps driven by APIs rather than traditional user interfaces, which are not well-received.

    Jefferson says those REST APIs are critical for any security company that wants to stay relevant as organizations start to manage multiple development pipelines that are tied into a common continuous integration/continuous development (CI/CD) pipeline. In that context, Jefferson says it’s no longer sufficient for IT security companies to make their offerings available as a virtual appliance. Security tools such as firewalls need to be just another cloud-native application that can be orchestrated as part of a CI/CD process, he says.

    What’s more, DevOps teams have made it clear they want to be able to consume anything deployed on a public cloud in the same manner they consume compute and storage resources. That requirement is driving companies such as Barracuda Networks to add a metered billing option because many organizations in the age of the cloud don’t want to pay for a firewall unless it’s actually in use, says Jefferson.

    It’s too early to say precisely how DevOps and DevSecOps are transforming the way IT products and services are acquired and invoked. In the case of Barracuda Networks, for example, the company is taking the rise of DevOps as opportunity to expand its portfolio of products first to include data protection by acquiring Intronis and then, more recently, compliance and archiving tools by acquiring Sonian.

    Naturally, not every IT organization is equally far down the DevOps and DevSecOps path. But the various walls that have isolated various segments of IT are finally starting to come down at an increasingly rapid pace across the enterprise.

    — Mike Vizard

  • Cloud Services Demand Security Up the DevOps Stack

    Cloud Services Demand Security Up the DevOps Stack

    In the era of soaring use of public cloud by companies, software delivery is moving away from an on-premises install approach to a cloud-based subscription model through software as a service (SaaS).

    Customers expect a lot when it comes to SaaS products and services. Whether they are investing in SaaS-first offerings or shifting workloads to cloud-based providers, companies no longer have upfront costs for hardware and related software or a reliance on costly labor to install, manage and secure it. They expect software that is easy to launch, upgrades that are unobtrusive and feature-rich and limitless scaling to meet their changing business needs.

    When it comes to security, the cloud-based subscription model significantly changes the paradigm of how software security should be treated. Fortunately for many cloud providers, customers trust that a strong foundational security and privacy posture has been built into to the service by design. Preserving that trust requires a healthy tension of shared responsibility between the security teams demanding it and the cloud providers offering it. A new paradigm shift requires a deeper acknowledgement that an emphasis of the security problem “up the stack” to the application layer is needed.

    For security teams, ensuring the protection is built in from the beginning and moves dynamically in lockstep with the workloads requires a much closer partnership with application developers and DevOps teams. This ultimately leads to a richer understanding of the business applications by security teams, creating a more cooperative business-aware and security-minded culture. Getting there will help reduce the tension and improve the overall delivery of secure cloud services regardless of where you sit in the cloud provider/consumer ecosystem and ultimately enables value creation to the business. To get there, a strong partnership must be fostered.

    There are obstacles to moving up the stack. In most companies, the reality is that many security teams are not well-aligned to keep up with this change while the business continues to make cloud-based investments, making the problem worse. Security’s comfort zone seems very much still focused on perimeter defense, but this emphasis isn’t optimally aligned to a cloud-first future. Even when forward-leaning security shops realize a need to change, they often get pushback from app developer teams because security reviews can delay deployment and security tools create “noise” and false positives for app developers. Also, traditional security tools often do not work well in cloud environments.

    Interestingly enough, the No. 1 concern of app developers is preventing data breaches and cyberattacks, a survey of 500 developers and development managers by Veracode found. Less than one-quarter of developers said meeting customer or regulatory compliance is their top concern, while 21 percent said meeting budget and delivery schedules is their top concern, and 19.4 percent said delivering secure code to pass internal audits is a priority. Furthermore, app developers who work with security teams get “major and tangible business and technical benefit,” according to a survey of 150 security and app development pros conducted by Forrester Consulting. Almost all of the collaborators said that working together leads to major or moderate benefit in customer satisfaction.

    Respondents said the more frequently they collaborate, the better the results, “including improved customer satisfaction, business/IT alignment, quality and frequency of releases, and the rate of innovation at their firms.”

    By overcoming barriers to collaboration, app developers and security teams can leverage this knowledge to improve their approach and also come to the table with solutions aligned at moving up the stack. First, they can perform code analysis to uncover vulnerabilities early in the app development process. Second, they can work on stronger runtime protection once the SaaS application is deployed. Code analysis can be used to make runtime protection better, and runtime data can be used to improve code analysis. This creates a continuous improvement loop between the two and both teams can work on code analysis and runtime protection together.

    To achieve this continuous improvement loop, companies must work to break down traditional work silos that exist because of a mismatch in expectations. App developers, measured for speed, need to receive security information accurately, early and with sufficient context to correct problems during software development. Security pros can benefit by installing security tools in production that understand the security needs of their applications, as opposed to tools that require security pros to write rules, tune the tool and then deal with large number of alerts.

    The goal is to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process rather than after deployment, when liability, revenue and reputational risks are the greatest. It is also important to realize that achieving zero defects in source code is a noble but difficult-to-achieve goal. Instead of focusing on extremes, the goal should be to establish a continuous improvement logic in CI/CD (continuous integration/continuous deployment), where bugs are identified, some are fixed and the remainder have fast and accurate runtime protection.

    This shift in thinking and processes will give companies fewer security worries and enable them to more proactively embrace a SaaS-first mentality with higher confidence and trust levels. Companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and improved levels of software security.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.

  • DevSecOps: Security Needn’t be Sacrificed for Speed

    DevSecOps: Security Needn’t be Sacrificed for Speed

    With the right practices, security needn’t be an impediment to continuous development and rapid improvement.

    The same cycle keeps repeating, according to IT security and risk management consultancy Sense of Security co-founder and CTO Murray Goldschmidt. A new technology is hyped, leading to rapid adoption, but security is left as an afterthought. It happened with WiFi and voice over IP (VoIP), he says, and is currently happening with the internet of things (IoT). But it doesn’t have to be that way.

    DevSecOps: DevOps + Security

    DevOps is good for making things better, faster. But there tends to be a culture clash between those talking about speed, velocity or agility and those concerned with issues such as control points.

    So Goldschmidt and his colleagues are showing their clients how security can be integrated into DevOps (DevSecOps) in an automated manner without affecting velocity.

    Most people with development, operations or cloud backgrounds aren’t well-versed in security, he suggests, so Sense of Security shows clients how DevSecOps means security and DevOps can run in parallel.

    “It’s not that complicated,” he says, but it’s something most people don’t think about.

    Organizations often have a vulnerability management life cycle to identify and treat issues. After all, that’s part of various industry standards.

    The typical approach is an annual penetration test to find issues, which can then be addressed.

    A better way is to move to automated testing, and there are various commercial and open-source products to do that job. Goldschmidt says he sees little resistance to this idea.

    The next step is to go from scheduling these vulnerability scans on a quarterly basis to weekly or daily—or even to run them continuously.

    Citing the Struts vulnerability that caused a big problem for Equifax, he notes the challenge is to identify vulnerabilities in your systems before an attacker does. Continuous automated scanning means the window of vulnerability is very narrow.

    This idea is simple enough, he says, but for some reason it doesn’t occur to most people until someone brings it to their attention.

    When a scan reveals a vulnerability, its significance (severe, medium, etc.) is used to prioritize remediation.

    “DevOps guys understand those triggers,” he observes: If you give them the data, they can take the necessary actions. For example, that might mean shutting down the servers in a small web farm one at a time, applying the patch, restarting and moving on to the next. They could all be patched and running by the end of the day.

    Patching Isn’t Everything

    However, “it is unfair to assume organizations can patch things quickly” every time, he says. For example, the Struts vulnerability required more than just a patch—the code running on it had to be recompiled and tested, and that process could take months in a large organization.

    So organizations should not rely on the idea that patching is the fix for a vulnerability. While patches will be applied eventually, if you can make it difficult to actually take advantage of any exploits, the risk of data breaches is very low.

    One very easy-to-implement example of these measures is using a stateful firewall to ensure inbound-only access to web servers. By disallowing outbound access—”the channel through which data is lost”—there is no path for data to leave.

    Goldschmidt also recommends using tools to examine in-house code and the open-source and commercial code that is used with it. Such tools can detect most common problems, including openings for SQL injection, cross-site scripting and token misuse.

    He describes these tools as being the equivalent of “spellcheck for developers,” and says it reduces the likelihood of putting insecure code into production.

    The market includes products from Veracode (now part of CA), Sonatype and Qualys.

    Qualys, he notes, provides differential reporting. This makes it obvious that something has changed, and “that is the key to automation.” Whether the system itself has changed or new information has been discovered about vulnerabilities or configuration issues, action is required.

    Furthermore, the ease of making configuration changes that could have security implications makes continuous scanning even more important.

    These checks should not be limited to individual modules. Rather, they should be repeated—preferably automatically—as modules are assembled to help developers avoid poor code and to check the overall product.

    RASP Away Some Attacks

    Runtime application self-protection (RASP) is another technology Goldschmidt advocates. The idea is to detect abnormal and possibly malicious activity. One example is that normal operation would see an application communicating with its application server, and the application server communicating with the database. If the application suddenly makes a direct request to the database—as happens in an SQL injection attack—action is clearly required.

    Depending on the situation, RASP might raise an alert or immediately terminate the application, among other possibilities.

    The use of these and other technologies and techniques should allow organizations to run at the pace implied by DevOps without sacrificing security.

    — Stephen Withers

  • DevSecOps: IoT Right and Nobody Dies

    DevSecOps: IoT Right and Nobody Dies

    Dr. Suzanne Schwartz, CDRH Associate Director for Science and Strategic Partnerships at the Food and Drug Administration (FDA), recently released a blog to update us on the FDA’s role in medical device cybersecurity.

    Cybersecurity risks in medical devices are nothing new. As far back as 2012, Sonatype published warnings of security risks in pacemakers that could lead to lethal attacks. Last year, Johnson & Johnson warned of cyber vulnerabilities in its insulin pumps. More recently, our “2017 State of the Software Supply Chain Report” shared details of pacemaker programming machines that were discovered to have more than 8,000 known software vulnerabilities (see page 37).

    When it comes to software in medical and other devices, cybersecurity will be a constant threat requiring constant vigilance. The encouraging guidance I read from the FDA blog was that cybersecurity should not be limited to devices already on the market, but that security needs build in throughout the product life cycle. Schwartz remarked:

    “It is the goal of FDA’s Center for Devices and Radiological Health to encourage a coordinated approach of vigilance, responsiveness, resilience, and recovery that fits our culture of continuous quality improvement.

    “This means taking a total product lifecycle approach, starting at the product design phase when we build in security to help foil potential risks, followed by having a plan in place for managing any risks that might emerge, and planning for how to reduce the likelihood of future risks.”

    In these two brief statements, Schwartz shares views that are common in many of today’s DevSecOps conversations. Perhaps she has been listening in?

    The first view is that we need to “emphasize the performance of the entire system and never pass a defect downstream” (Gene Kim’s first way of DevOps). Schwartz recommends that device manufacturers start by building security in at the earliest stages of the development life cycle. Security cannot be an afterthought.

    Schwartz also recognizes that even when precautions are taken early in the life cycle, risks can emerge over time as new vulnerabilities are discovered. When it comes to device security, vigilance must be continuous across the development life cycle and over the product’s life in the market. As we have said for years, software ages like milk, not wine. Constant vigilance improves our ability to identify risks, initiate feedback to development teams and remediate issues in the device’s software. The faster we can address risks when they appear, the safer we can make the lives of consumers who rely on them.

    I applaud the FDA’s guidance and its proactive stance here to work with device manufactures. What we don’t want is a knee-jerk reaction to medical device security after someone has died. What we need is for security to be ingrained in the planning, design, production and maintenance of medical devices our families rely upon.

    You can read the full blog from Schwartz on the FDA Voice.

    — Derek E. Weeks

  • Bringing Balance To The Force Between DevOps And Security

    Let’s not kid ourselves—I am not sure there ever has been balance among Dev, Ops and security. But with the advent of DevOps, automation and the cloud, whatever balance there was between DevOps and security seems to have been lost. DevSecOps, or DevOps Security, has sought to restore the balance between DevOps and security. At the end of the day, though, it can appear as though they are still working at loggerheads. See the illustration below:

    devops and securityHow do you bring balance to this equation? A new approach, perhaps? Puppet and CloudPassage have teamed up on a white paper that does a decent job of outlining the issues here and suggests some solutions. The diagram above is taken from that paper, as a matter of fact. The paper is titled, “A New Approach for Security DevOps Environments in the Cloud.” You can download it from our download library.

    While there are no magic bullets for making Dev, Ops and security head down to the beach and sing “Kumbaya,” there are things you can do to make a real partnership here. That includes shifting security left and working with DevOps tools such as Puppet, Jenkins and others. But most important is making members of each team feel like they are all part of the same team. All the tools and APIs in the world don’t take the place of good culture and fostering a “we are all in it together” mentality. It’s all in this white paper, so download it—and, while you’re at it, check out the several other great DevSecOps assets available in our library.

    Our download library is quite stocked with lots of useful content. If you are looking to learn about DevOps and related subjects, it is a great place to start.

     

    — Alan Shimel

  • DevOps Connect: DevSecOps Days @ RSAC Call For Speakers Is Open

    DevOps Connect: DevSecOps Days @ RSAC Call For Speakers Is Open

    For the 4th year devopsy.kinsta.cloud is proud to be producing DevOps Connect: DevSecOps Days @ RSA Conference. The event will be on Monday, April 16th, 2018. RSAC is the world’s largest security conference and so the perfect place to hold what we think of as the best day of DevSecOps. You can get full details at the DevOpsConnect.com site. The call for speakers is open now through December 15th.

    devops connect: DevSecOps Days 2018 @ RSAC

    Why Speak at DevOps Connect: DevSecOps Days @ RSAC

    If you have a great DevSecOps story to tell, this is the conference to do it at. Last year we had almost 1000 people stop in during the full day of sessions to catch some of the top speakers in the space, as well as many up and coming thought leaders giving us a fresh look at the latest trends in DevOps and security. This year we expect over 1200 people or more to attend the sessions. Sessions are also video taped and then put up on DevOpsTV for later viewing.

    It is a large stage that gives our speakers a great pulpit to share their expertise and experiences. The fact that it takes place on the backdrop of the largest security show in the world means the spotlight is even brighter.

    More importantly, this is your chance to lead. Your chance to give back to the community as we forge a road ahead towards better, faster more secure applications. Unlike some other conferences, there is a strong preference here for speakers to be practitioners in the space rather than vendors selling to it (though not all vendors are bad, they speak with more practitioners than anyone and do add to the body of knowledge). So there is a strict, no vendor pitches policy.

    What Are We Looking For?

    In fact here are some of the guidelines we are looking for:

    We are looking for practitioners to discuss the unique challenges of adopting security into the DevOps pipeline, the obstacles to security being a contributing and valued partner in DevOps and the ways to overcome them. Specific topics we are looking for include, but are not restricted to:

    • How did you get senior management buy-in? What did you do? How did you quantify the business value?
    • Examples of security teams being integrated into the CI/CD or DevOps process
    • How did you overcome objections inside the organization?
    • How did you design and implement effective controls to mitigate security risks?
    • Which business area (and application) did you start with, why, and what did you do?
    • What were the top challenges, and how did you overcome them?
    • What were your top mistakes, and what advice would you give as a result?
    • In-progress stories (and even nightmares) are welcome!

    Also, beyond the practitioner preference, we are looking for a diverse set of speakers that closely matches the real world. There will be something approaching 50,000 people attending RSA Conference this year. We want DevSecOps Days to reflect that diversity.

    All speakers receive passes to DevSecOps and an expo pass to RSAC itself.

    How You Can Attend DevOps Connect: DevSecOps Days @RSAC

    If you aren’t ready to share your DevSecOps story with the world quite yet, you can still participate and attend DevSecOps Days @RSAC.  All you need is any kind of pass for RSAC. If you are not speaking and have not purchased a ticket yet, or would like a complimentary Expo Hall pass on us, please use these codes.

    • $100 Discount off of Full Conference passes – 18UDEVOPSFD
    • Complimentary Expo passes – 18UDEVOPSXP

    The free expo pass is enough to get you into DevSecOps Days and expo show floors all week, as well as the keynotes. The $100 discount is off a full conference pass good for all sessions.You can register using the codes above at: https://www.rsaconference.com/events/us18/register

    Wait, there’s more

    Following the day sessions, the 5th annual No Wine-ing DevSecOps Cocktail party will take place @ Jillians, San Francisco, 4:30pm till 6pm, down the block from the Marquis. Registration for the No Wine-ing event is required and attendance is free. Register here.

     

     

    The Security @ the Speed of DevOps panel and luncheon, featuring an all star lineup of DevSecOps experts will take place on Tuesday, April 17th, 11:45am, again @ Jillians. The panel will be based on the 2nd annual Security @ the Speed of DevOps reports by George Hulme. Once again admission and lunch are free, but registration is required. Printed copies of the report will be available to attendees.

    So if you would like to tell your DevSecOps story to the world, please apply to speak at DevOps Connect: DevSecOps Days @ RSAC. But whether you do or do not, if you are going to be in San Francisco on April 16th, please join us for what should be another great day of DevSecOps learning, networking and growing at RSA Conference.

    Also many thanks to our sponsors, Sonatype, White Hat Security, Aqua Security, CA Veracode, Checkmarx. If you are interested in sponsoring, write sponsor@devops.com

    — Alan Shimel

  • How to Make Your Software HIPAA-Compliant

    How to Make Your Software HIPAA-Compliant

    Creating software for the healthcare industry must always follow strict requirements and limits set by both state regulators and medical organizations. In this article, we will focus on becoming compliant with HIPAA (the Health Insurance Portability and Accountability Act of 1996) by building a proper IT solution for corresponding institutions, while also considering the HIPAA compliance software checklist.

    By the end of 2017, the North American healthcare IT market is forecast to value $31.3 billion. According to Healthcare IT News, the annual growth rate is about 7.4 percent, which will allow the market to become almost $10 billion bigger than it was in 2012. Why has the market grown so fast? The main reason is the need to implement more IT systems in medical organizations, thus creating a higher demand. Of course, there are also other factors that drive market growth.

    Other factors that increase the healthcare IT market include:

    • A growing pressure to cut medical costs;
    • A high demand for healthcare system integrations;
    • A higher ROI due to implementing IT systems in health care;
    • Serious governmental financial support;
    • The need for computerized physician order entry (CPOE) adoption; and
    • Aging populations.

    Healthcare IT tools must correspond to all HIPAA requirements to make medical institutions integrate them. Let’s talk about the major aspects of software development in this industry.

    How to Become HIPAA-Compliant

    Here, we will cover the elements that must be implemented in software for medical organizations to ensure HIPAA IT compliance. Based on the following recommendations, developers can adopt the features they need to adhere to all requirements.

    Audits

    According to the Act, healthcare providers must perform regular audits to identify possible risks for data breaches or privacy violation. A HIPAA-compliant software should utilize these audits to analyze the compliance level of a particular medical organization and provide it with detailed information concerning risks and current errors, including recommendations. The audits may include a form of quizzes, which will make them easy to use for medical staff.

    Recovery Plan

    The above-mentioned audits will help forecast risks or detect errors related to HIPAA compliance. On the other hand, a remediation plan will allow healthcare providers to correct mistakes and prevent their reappearance. That is why such plans have to be included in medical software. Furthermore, every medical institution has to develop its own recovery plan, taking into account its specialization and implemented systems. The software should be able to initiate a particular plan for a specific situation.

    Documentation

    The main task of any medical software is to work with documents. Since the software helps facilitate documentation processing, many healthcare providers implement such systems in their organizations.

    Required principles, which software development organization Archer Software uses in its own projects, for medical software in documentation processing include:

    • Comprehensibility;
    • Simplicity;
    • Strict structure; and
    • Secure data storage

    HIPAA violation fees are huge. The price of breaking a rule can reach up to $1 million. Reliable data storage, which protects from hacker attacks, will allow organizations to save money and ensure electronic protected health information (ePHI) security.

    Managing Relationships with Business Associates

    HIPAA-compliant software must also handle the company’s relationships with its business associates, including contractors responsible for managing ePHI. A system must monitor the execution of specific agreements regulated by the Omnibus Rule of HIPAA. This will help healthcare providers ensure the security of PHI while entrusting it to business associates.

    Security

    It is almost impossible to fully exclude the risk of data breaches in any medical organization. Software must be able to detect those breaches, create a corresponding report and apply preliminary measures to avoid further data “sharing.” It also has to prevent data breaches by blocking the use of portable data storage devices.

    HIPAA Compliance Checklist for Software Development

    Below is a list of all the necessary elements for HIPAA-compliant software, based on the safeguards listed in the HIPAA Security Rule. The implementation of these elements will allow your software to ensure both ePHI security and privacy.

    The necessary features for HIPAA-compliant software include:

    • User authorization;
    • Access control;
    • Authorization monitoring;
    • Data backup;
    • Remediation plan;
    • Emergency mode;
    • Automatic log off; and
    • Data encryption and decryption.

    Now that we’ve covered off the requirements for IT solutions designed for medical organizations, let’s proceed to the aspects of hospital management software development.

    Hospital Management System Development

    Besides HIPAA rules, custom hospital management systems (HMSs) have to correspond to other internal requirements that will allow medical staff to get as many advantages as possible from using the medical software without compromising patient privacy or data security.

    The requirements for HMSs are as follows:

    • An HMS has to be comprehensive for any medical employee.
    • The UI must be highly informative and laconic.
    • The system has to have a user access control based on employee responsibilities.
    • An HMS must contain a reliable security system that encrypts stored data.
    • The software has to provide functionality for extending or improving clinic automation.

    Taking into account the tremendous financial penalties for violation of HIPAA principles, healthcare institutions strive to implement IT systems that fully correspond to the requirements of the Act. That is why software developers have to be aware of new state requirements in the healthcare industry to offer medical organizations convenient IT solutions at a reasonable cost. This is especially crucial for startups just entering this market. This knowledge will allow healthcare providers to get HIPAA compliant software and help IT outsourcing companies grow their business.

    About the Author / Adam Edmond

    Adam Edmond is a technology writer, interested in the cloud, app and software developing niche. However, he can’t stand mathematics. Edmond has also lead courses in visual effects, animation and digital marketing for both the Western Australia School of Art and Design and Murdoch University. Connect with him directly.