devopsy.kinsta.cloud

Tag: privacy

  • How DevOps Startups Can Deal with GDPR in 2018

    How DevOps Startups Can Deal with GDPR in 2018

    Data protection is not a new issue. There have been numerous high-profile data hacks in recent years, with sensitive customer information released into the public domain, causing widespread condemnation and fury. Trust is a big issue. When Equifax revealed hackers had stolen the personal information of 145 million people, there was an uproar. The problem is that we are increasingly moving our lives online. Criminals have been quick to realize that data equals serious money. For this reason, DevOps startups need to pay close attention to the new GDPR data privacy regulation changes that are set to come into effect May 25.

    What is GDPR?

    The General Data Protection Regulation (GDPR) is an EU Data Protection Directive. It has been carefully designed to shape the way businesses deal with data privacy and has been described as “the biggest change to data protection law for a generation.”

    The new directive will apply to all startups and businesses operating in the EU, and any company that holds data related to EU citizens. So, if your CFD trading startup is based in the United States, but you retain data on customers who reside in France or Germany, you are bound by the GDPR.

    Data compliance is a huge issue. Cyberthreats are common and criminals are happy to take advantage of businesses that have left a backdoor wide open. Secure data management is not something DevOps startups can ignore. Any data stored in the cloud or on a server must always be protected.

    Many tech startups hold significant amounts of information. This helps them deliver a software solution more effectively. However, even if your company holds no customer data, if any of your development team are EU citizens you still must adhere to the regulations. And with many DevOps startups recruiting remote employees from far and wide, this is not as unlikely as it may first appear. So, if Carlos from Barcelona is a key player on your development team, GDPR will apply to your startup.

    Company and Customers

    GDPR is split between company data and customer data. For a small startup, it may be a case that employee data is more of an issue, but if you hold customer data, it is time to look at how you manage this data. A good way to do this is through an internal audit.

    Create a data flow diagram (DFD) that maps all the data that enters, is processed and stored and exits your systems. Provided with a good overview, you should be able to spot any data that isn’t required or needs modifying so you can remove or adapt certain funnels to save time attempting to meet compliance measures for data you don’t use.

    Planning and Preparation

    GDPR is a big step up from the Data Protection Act, so you can’t sit around and wait for May 25 to come and go. It’s vital that you examine the GDPR in detail to see how and if it applies to your organization. If it does, you will need to make organizational changes to the way you deal with data.

    Create a compliance checklist to be adequately prepared, based on the requirements from the National Institute of Standards and Technology (NIST) and Cloud Security Alliance (CSA), combined with any state or regional regulation.

    Hire a Governance Trainer

    Legal language used in compliance can be difficult for those from an engineering and IT background to comprehend. Hiring an external compliance by design practitioner or trainer will help in this respect. Ensure they have a good technical as well as legal knowledge so that they understand both sides and are able to accurately review processes, make suggestions and make sure that GDPR compliance is met.

    Task this person with downloading the Control Objectives for Information and Related Technologies and CSA requirements. They can then work with program management to put such company directives into play, alongside working with your checklist. This checklist can be used to create an open source tool for scrubbing applications and determining whether they should be onboarded or pushed back, depending on whether they meet the compliance policies.

    Notifying Employees/Customers of a Breach

    If customer or employee data is breached, accidentally or otherwise, you have 72 hours to notify them. Sticking your head in the sand and hoping it all “goes away” will not cut it. There are two tiers of fines for non-compliance: up to 10 million Euros or 2 percent of turnover, or up to 20 million Euros or 4 percent of annual turnover.

    To ensure this risk is minimized, hold everyone accountable and put in place consequences. Decide on what these will be and how they will be enforced to best implement GDPR compliance in your startup, as such hefty finance can be especially damaging for small businesses.

    Data Consent

    You must let individuals know if their data is collected. Consent is a major issue in the GDPR and ambiguous tick-boxes are not acceptable. Privacy notices must be crystal clear and written in Plain English. Clients must have the option to opt-in or opt-out if you collect data from them.

    The Right to Data Erasure

    All individuals have the right to request that their data is permanently deleted. So, if Carlos from Barcelona decides to jump ship to another DevOps startup, he can legitimately request that you delete his HR file. He can also ask you to send his file to his new employers.

    Data Protection Officer

    Companies that process large amounts of data or are involved in the monitoring of individuals—this is applicable if you track online behavioural patterns for marketing purposes—must appoint a data protection officer. This person can be anyone, but they must have knowledge of data protection practices and the law related to data protection.

    Not everything has to cost in meeting GDPR data compliance, though; there are many free resources your startup can use as well.

    Speed

    One concern is the impact on speed that GDPR will bring. Eighty-one percent of IT operations professionals believe information security policies slow them down. Avoid this for your startup by doing the DevOps yourself as it will make software deployment faster. However, insecure system changes could then be shipped through. Automation can offer a solution.

    Automation

    Treating compliance through continuous automation means your DevOps startup will put code-based controls through the normal development process: test, version, apply and modify. This makes such controls easy to collaborate on and running compliance scans will become a common feature in the development stage, testing environments and production systems.

    The average idle time before identifying a system breach is believed to be 200 days. Continuous automation means that such an issue could be detected on the engineering team’s development workstation, before it reaches production and ensuring it is dealt with to make things safe and guarantee GDPR compliance.

    What Not to Do

    The thing you absolutely shouldn’t do is ignore GDPR on the basis that it doesn’t apply to you, “because who’s going to know if Carlos from Barcelona works for my startup and so what if one of my computers is struck with ransomware and everyone’s bank details are leaked onto the Dark Web?”

    The GDPR will affect millions of businesses, so all startups need to be aware of how it will affect their operations. If you don’t comply with the directive, it could prove to be a costly mistake. Ignorance is never a legitimate defense in the eyes of the law, so check out the EU GDPR website and get informed. If GDPR doesn’t affect you, great; but if it does, think like a Boy Scout and Be Prepared.

    — Murray LeClair

  • What GDPR Means to You, and Other Important Questions

    What GDPR Means to You, and Other Important Questions

    The EU’s General Data Protection Regulation (GDPR). It seems that everyone has questions about it, and for very good reason—GDPR goes into effect May 25. You may be too overwhelmed to even think about developing a knock-out action plan to move your organization toward compliance, or maybe you’ve had your head in the sand. CA Technologies’ Jeff Hughes, senior principal product marketing manager, and devopsy.kinsta.cloud founder Alan Shimel recently discussed a number of questions regarding this upcoming legislation and how companies like yours, should prepare for the May deadline.

    Here are the Top 10 GDPR questions from their Jan. 11 Live Chat:
    [su_list][su_list icon=”icon: circle”]

    • What is GDPR, in a nutshell?
    • What is the biggest thing that companies need to know about GDPR, especially those companies outside of the European Union?
    • What are some of the differences between data privacy in the United States and data privacy in the European Union?
    • How are companies going to need to structure their communications with end users when discussing their personal data?
    • What kinds of tools are needed to address GDPR?
    • How prepared for GDPR are companies?
    • Will fines for non-compliance be levied?
    • How should companies approach GDPR from a management standpoint?
    • Do companies need to appoint a data protection officer?
    • What strategy is recommended to address GDPR?

    [/su_list]
    Sound familiar? Click here to watch Jeff and Alan’s interactive GDPR discussion and hear the answers to these Top 10 questions (and more) about GDPR.

    GDPR is one of the biggest changes to hit the digital privacy landscape in 20 years. Make sure your organization has a knock-out action plan to prepare for GDPR. Don’t let GDPR give your company the Left Hook!

    Links to additional information:

    CA GDPR Webpage

    — BeckyArenson

  • 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.

  • DevOps: Here’s How to Slack Securely

    DevOps: Here’s How to Slack Securely

    With 1.7 million daily active users, it’s clear Slack has come to dominate the team chat world, especially in the tech industry. This, however, means that a fair amount of security is required to ensure that strategic assets remain safe.

    From a security perspective, Slack has done a solid job of keeping its assets on lock, going so far as to score Geoff Belknap from Palantir in 2016 as its chief security officer. The company is also transparent about its approach to security and has dedicated a whole section of its website to it, including interviews with Belknap and others that delve into Slack’s precautions and philosophy around security.

    The company has also certified many of its products to meet strict compliance regulations including FINRA, HIPAA and SOC 2 and 3, which makes it a no-brainer for small teams and enterprises alike.

    So, it’s perfectly possible for companies of all shapes and sizes to lean on Slack for team chat and ops without worrying too much about security. However, no one’s perfect, and Slack’s ubiquity and popularity mean it will always be a target for cybercriminals looking to steal information—that’s basically the nature of being a cloud-based application.

    While, there’s no need to run scared, you do need to be smart about how you use this valuable tool. Here are a few tips for running Slack securely at your organization.

    Use Slack for SecOps

    Slack can be easily used for distributed security alerting, which means every member of your organization can play a role in keeping the business secure.

    Your security operations likely include members of the DevOps team as well as dedicated security folks, and Slack can help all team members integrate security into their workflows seamlessly. DevOps folks may not frequently log in to Threat Stack platform directly. However, any relevant alerts or notifications can be sent to them immediately via Slack, where they can be reviewed and the determination can be made whether further action is needed—all without having to step outside the daily workflow. This means security tasks don’t pose an extra headache, but are just a natural part of the way the company’s operations run.

    Require Two-Factor Authentication

    Slack’s built-in security precautions won’t do you much good unless you actually put them into practice. One great example is two-factor authentication (2FA). It’s up to team owners and admins to require this of their users (otherwise, it will be optional, and most users won’t bother). It is highly advisable you take advantage of this feature, which makes it much more difficult for hackers to tap into your organization’s Slack channels.

    Set Up User Provisioning and Deprovisioning

    Security-minded organizations need to be conscious of and work around insider threats. This also includes employees who have left the company, whether on their own terms or due to an incident.

    To ensure that you do not have any “lurkers” who might be able to take advantage of company information shared on Slack after they have left the company, it’s a good idea to plan ahead for user provisioning and deprovisioning.

    In fact, this should be built into your process for onboarding and offboarding employees, just like it would be for email or any other company asset. If possible, automate the process, so that the moment someone leaves the company, they no longer have access to Slack. To get started, here’s Slack’s guide to provisioning and deprovisioning users.

    Don’t Share Secrets

    Slack is a great place to have secure conversations, which unfortunately can lull some users into a false sense of complete security. “Secure” doesn’t mean you should treat it like it’s watertight; in other words, Slack should never be used to share secrets such as passwords, sensitive customer data or valuable corporate IP—basically, anything that could be considered highly confidential. A good rule of thumb is this: If a piece of information could be dangerous in a hacker’s hands, it doesn’t belong on Slack. Instead, it’s a good idea to use encrypted communication channels, like PGP-enabled email.

    Educate Users

    None of the tips above will do your organization any good if no one knows about them. So make sure that you regularly educate your users about steps they need to take to stay secure while using Slack (such as never sharing passwords there). You should hold user security training whenever new employees come on board, and also make sure to do a refresher now and again with the entire company.

    Additionally, if you change up security protocols around tools like Slack, make sure employees are given a heads up and reminded when new measures go into effect so they know what to expect. Remember: The best offense is a good defense.

    Don’t Slack on Security

    Slack is a great platform with all kinds of benefits for teams. As long as you take the right security precautions, there’s no reason why it can’t be used to its full potential on your team, whether you’re a small shop or a multinational enterprise. As with any other tool, the shared responsibility model is key. Take responsibility for your half of the security equation, and you should be well on your way to a secure Slack implementation.

    — Pete Cheslock

  • Private Practice: Encryption Exposed

    Private Practice: Encryption Exposed

    In September 2014, Apple made encryption a default with the introduction of the iPhone 6. Then, in February 2016, a Los Angeles judge issued an order to force Apple to help break into the encrypted iPhone belonging to a terrorist involved in a mass shooting.

    Apple had used some of the strongest encryption technologies and practices to protect its users and their data. The encryption technology did not discriminate between lawful and unlawful users. While there were many sides to this issue, it surfaced many important debates on security, privacy and civil rights.

    Peekaboo

    For developers wanting to add cryptographic libraries to their applications, a number of open-source components are available to them. Of course, anyone seeking to add encryption to an application has an important requirement for the privacy and security it provides.

    One of the more popular choices for encryption is known as the Legion of Bouncy Castle Java Cryptography library. According to the “2016 State of the Software Supply Chain” report, records reveal that 17.4 million Bouncy Castle components across all versions were downloaded last year. Of these, 5.8 million (33 percent) were known vulnerable versions of Bouncy Castle.

    peekabo

    It’s a sobering fact, but it’s true. Last year alone, organizations downloaded vulnerable versions of the Bouncy Castle cryptography library 5.8 million times. The defective components downloads occurred across 93,253 unique IP addresses from 13,824 organizations in 197 countries.

    Think Different

    Think about it. The Bouncy Castle project is developed by experts in cryptography. Occasionally, their crypto library is discovered to have a flaw and the project owners rapidly fix and release a new version. If you use the latest versions without known vulnerabilities, your application, your users and your data are protected. If you use the versions that include known vulnerabilities, you have electively declined those protections.

    Two of the critical principles of using open-source components are to use the highest quality components and to select them from the best suppliers. In this case, the Bouncy Castle project does an excellent job of releasing new and improved versions. While flawed versions are still available, those seeking to protect applications, users and data need to use the highest quality versions.

    Which Version Are You Using?

    Determining which versions of Bouncy Castle or any other open-source component you are using is simple. A number of free and paid services are available to help you analyze your application and report a full list of the components, including dependencies, that are used.

    Some of the free services require you to upload your application for analysis while other services are performed on-premises. One example of a free on-premises tool used to create a software Bill of Materials is the Application Health Check app from Sonatype. Another example is the OWASP Dependency Check app. Precision of these tools may vary, but regardless of the tool you use, you should use one.

    More insights on the quality, security, and integrity of open source components used to build modern applications can be found in the “2016 State of the Software Supply Chain” report.