devopsy.kinsta.cloud

Tag: compliance

  • DevOps Spring Tour 2015: Keeping Cool with ICE

    DevOps Spring Tour 2015: Keeping Cool with ICE

    One thing I love about conferences is finding out what other people are doing in industry and getting exposure to new ideas. I like to get external feedback on my work because I find it to be helpful. Here’s some highlights from where I’ve been and what I’ve heard so far in 2015, including Alterconf, RSA, A Data Presentation Course with Edward Tufte, and DevOpsDays NYC.

    AlterConf

    My first stop was Alterconf in Atlanta this year. I try to support local events and knew I would gain a lot of perspective from the presenters that I probably wouldn’t find elsewhere. There was a lot of discussion about age bias and discrimination for both younger and older people as we all move through those stages during our lives. Starting a culture of continuous learning early in life was a consistently supported goal among the presenters and attendees.

    My other take away from alterconf is people may or may not be comfortable representing or discussing the different groups they belong to with anyone. Introverts can have a very difficult time talking tech at an event, for instance.  Several speakers at the conference made note of the fact that we will occasionally step on each other’s toes due to what are ultimately misunderstandings and we should be quick to apologize, provide space, and try not to get too upset when someone makes a mistake or appears uncomfortable. I was encouraged to see the consensus lean towards discretely and respectfully bringing any issues up if necessary instead of public exposing someone. Even snapping at a manager in a meeting over a wisecrack about a father ‘babysitting’ his own kids does more harm than good. You shouldn’t stomp on anyone with both feet over failed build either. Having a calmer conversation with a smaller audience if possible was the advice I heard repeatedly throughout the day.

    We’ve been having more conversations around anxiety and burn out as a community and talking a lot about comfort, learning, and danger zones. I’m going to openly admit I was more nervous than usual going into alterconf as a white cisgendered heterosexual male. It may have had something to do with the fact that I didn’t know what cisgendered meant before the event. The anxiety quickly passed after I found my seat and realized there were plenty of people there just like me. At a minimum all of us were passionate about technology. It was a very open and welcoming space and I gained a lot of perspective that I wouldn’t have otherwise. There are 5 more sessions scheduled this year if you may be interested in gaining some perspective from a broader range of people that are also passionate about tech.

    DevOps Connect @ RSA

    DevOps Connect @ RSA was a uniquely awesome experience. I met a lot of security folks coming into the DevOps space for the very first time which was encouraging to see. I also got an up close look at the security industry and why they need to gain some insight from a DevOps perspective. The expo floor was the most commercialized one I’ve ever seen at an event. It reminded me of a midway at a state fair. I wouldn’t have been shocked if someone had called me in for a go at the ring toss. Most of the sales pitches sounded like magic beans to me, bolted on for instant risk mitigation.

    The one vendor that separated themselves as an exception to this was Tufin. Tufin’s security orchestration suite is a comprehensive solution for network security management providing visibility, change tracking, analysis and auditing for firewall policies, network devices and cloud platforms. It also provides automatic firewall change management and application connectivity management. It assures a tight security posture, rapid service delivery and regulatory compliance across all enterprise platforms.

    I haven’t taken it for a spin myself, but Tufin definitely impressed me with their demo and orchestrated approach to the problems security is currently facing.

    Certification was also a consistent topic of conversations at RSA. I think there’s a lot of misunderstanding in this space between arbitrary compliance and compliance that legitimately mitigates risk or provides a return on invested time and energy. This sentiment echoed through Secretary Jeh Johnson’s keynote, as he announced the opening of a satellite cyber security office in Silicon Valley and an invitation to cooperate with concerns surrounding encryption.

    Data Visualizaiton Workshop with Dr. Tufte

    My next stop was Boston for a data visualization workshop with Dr. Edward Tufte. When I told him I was a devOps engineer working on dashboards in an enterprise environment I could tell he was curious but may have not heard the word devOps before. The person I was speaking with before Dr. Tufte came by mentioned a health care system that still faxed data between offices and the problems it caused with younger employees that had never used a fax machine before. It was obvious to Dr. Tufte that they should switch it to a web based system, and the frustration with compliance and risk concerns that prevent that change from happening were not lost on him. For lack of better words and opportunity, I offered this as the type of problem devOps is currently trying to solve. The perspective I gained from the session that followed was from an experienced professional that can fully appreciate the current state of the art. I believe I appreciate it now more than ever, for which I’m thankful.

    DevOpsDays NYC

    The topic of discussion was ICE, or Inclusion, Complexity, and Empathy, based on a post by Dave Zwieback from earlier this year. The talks focused on how to try to cooperate better between teams both at home and abroad and suggestions on how to handle departments that are more territorial in addition to dealing with our own stress levels.

    Attendees seemed particularly grateful towards John Willis and Justin Lintz for talking about burn out and anxiety in our industry among heavier topics. If you’re inclined to start a conversation about these types of health issues in your community then you probably should. I try to shut up and listen as much as possible, and that’s often helps more than one would think. If you have a venue to show John’s video before an open spaces event all you have to do is book the room and be available. Creating an opportunity to discuss these issues is a huge step forward in my opinion.

    But wait! There’s More! I’m giving an Automating Enterprise Security Talk at Gluecon outside of Denver later this month. I spoke about this at devOps Connect @ RSA but I always update my content between talks as I get more feedback from folks. If you happen to be at Gluecon this year we should have a conversation over coffee, a beer, or a meal. From my experience a chat tends to be more fun in person than online, as I for one get tired of staring at screens all day.

  • A Three Step Roadmap for Enterprise DevOps

    A Three Step Roadmap for Enterprise DevOps

    The extremes of application release velocity are converging in the enterprise. Whereas Fortune 500 enterprises may have historically taken months to years for each release cycle, they are exploring new approaches from new age Internet technology firms that release new versions of an application several times in a day.

    According to a recent report on DevOps adoption, 86% of IT and business decision makers have either implemented DevOps or will roll out DevOps initiatives within the next 3 years. There is a strong appetite for enterprise DevOps, but where do you start?

    For DevOps projects, Ops will need to shift from a systems management approach to a programmatic approach. Ops should work with Dev to figure out the automation required to provision and deploy the application. Here is a three step roadmap for enterprise DevOps for those organizations looking to roll out successful DevOps initiatives:

    Step 1: Select The Right Application Candidates.

    Not every enterprise application is a right candidate for DevOps. Traditional applications are not architected for DevOps velocity, whereas enterprise applications designed with agile and iterative techniques are excellent candidates for DevOps. DevOps may be an overkill  for applications where the underlying business process rarely changes. Dev and IT Ops should choose one or two applications for DevOps style implementation.

    Step 2: Manage Your Application Lifecycle With Automation.

    Provision applications as part of the build process itself. During deployment, Ops should be able to execute a piece of code to identify application monitoring needs. Your automation framework should manage application health without manual intervention.

    • Can you fix application issues using runbooks?
    • Do you have scripts for scaling, maintaining, and load balancing the application?
    • How do you plan for new releases?
    • How do you upgrade the application?

    Treat your infrastructure as code. Application configuration, deployment, and maintenance all need to be part of an automation framework. Ops should build concurrency with the application. You should be able to configure, deploy, and bring the entire application live within no time.

    Step 3: Embrace Compliance Driven Operations.

    Your IT Ops automation framework should deliver the right visibility to support more frequent releases without complex manual processes.

    • Are you able to automate monitoring of the infrastructure for delivering the best end user experience?
    • How do you ensure that the right infrastructure resources are available for running the application?
    • Can you keep your infrastructure current by maintaining the right patch levels?

    Enterprises can modernize application delivery pipelines by selecting the right application candidates, managing application lifecycles with automation, and embracing compliance driven operations. While you might never deploy code 23,000 times a day like Amazon.com, the Enterprise DevOps framework will help you release applications faster, with higher quality and lesser risk of deployment failure.

    About the Author / Varma Kunaparaju

    YaCNNVuUVarma Kunaparaju is CTO at Vistara and a seasoned technologist with over 20 years of experience leading engineering teams to deliver enterprise software. Reach him on twitter at: @varma1

     

  • Building Security and Compliance into the SDLC

    Building Security and Compliance into the SDLC

    As the concept of DevOps has become more popular in recent years, there are some common themes that always seem to come up in discussions about it. For example, how often do we talk about ways to speed up the software development life cycle (SDLC) in order to bring innovative applications to market faster and meet ever-increasing customer demands?

    As important as this and other popular DevOps themes may be, though, they often have the side effect of overshadowing some of the less glamorous topics, such as security and compliance, which is often viewed as a sort of “necessary evil.” That said, the risks of putting an unsecure application into production can create massive challenges for organizations – from breaches to loss of company IP to brand damage – making security and compliance a topic that must be tackled as enthusiastically as accelerating innovation.

    Three Critical Areas of Focus

    When it comes to considering how security and compliance can become more integrated with DevOps practices, there are three critical areas on which all organizations should focus: shifting security left in the SDLC, building security into policies and creating an audit trail throughout development.

    Shifting Security Left in the SDLC

    Organizations that incorporate security in the earliest stages of the SDLC will ultimately benefit from products and applications that are secure by design. But in order to accomplish this, they can’t wait until the software hits production to test it for vulnerabilities.

    Service virtualization can help by simulating the application delivery run-time environment and its data, allowing developers and testers to focus on security immediately, instead of waiting for access to crucial resources. In addition, a release automation tool can help collapse development cycle times from days to minutes, enabling IT teams to spend more time improving the functionality, quality and security of their applications – and less manually promoting them from stage to stage.

    Building Security into Policies

    It used to be that every element of application development took place between an organization’s four walls, but with the rise of cloud and software-as-a-service (SaaS) technologies, it’s not uncommon for different stages of the SDLC to occur on different infrastructures. So if the environments are always changing, how do we ensure security is consistently addressed? By building it into the policies that comprise our continuous validation methodologies.

    Release automation enables development teams to create policy-driven infrastructure provisioning rules that automatically determine what application elements can and cannot be staged on specific infrastructure types. For example, a common policy would be to never let customer or database information move to a public cloud environment, where sensitive information could be lost or stolen.

    Creating an Audit Trail through Development

    To this point we’ve centered the conversation mostly on security, but being able to maintain – and prove – compliance throughout the SDLC is an equally important challenge that IT development and operations teams must solve.

    So when we think about compliance, we’re really asking questions like “What application moved from this stage to that stage?”, “Who released the application into production?” and “If there was a rollback, what was the cause and who rolled it back?” In other words, we’re talking about audit trails and logging all activities within the SDLC – something that can be difficult when numerous manual steps are involved. However, a release automation tool will capture all of this data as a matter of course as it automates release deployments through orchestration and promotion of applications from development through production. This means you’ll always be able to answer those who, what, where and when questions that pop up during audits.

    Eliminating Vulnerabilities and Getting Back to the “Good Stuff”

    I’ll admit that security and compliance are not the most exciting topics in DevOps. If application development were a meal, they’d be the pile of lima beans you have to eat before you get to the dessert that is innovative feature development. The good news is, service virtualization and release automation tools can help you speed and simplify the process of building security and compliance into the SDLC, which ensures your applications will hit the market without vulnerabilities – and lets you get back to the fun stuff.

  • National Renewable Energy Laboratory Uses DevOps For Better Compliance

    National Renewable Energy Laboratory Uses DevOps For Better Compliance

    One of the big stumbling blocks naysayers claim DevOps can’t overcome is the perceived incompatibility of DevOps with high levels of compliance regulations. But forward-looking IT practitioners at financial institutions, healthcare organizations and government agencies alike have already started to show how untrue that perception really is.

    The National Renewable Energy Laboratory (NREL) recently offered a perfect case study in this phenomenon. Not only do the key IT staffers in the trenches at NREL believe that DevOps is compatible with DevOps, but they actually used DevOps and continuous delivery principles to help the agency deliver compliance with a key piece of regulation around cloud integration within the NREL infrastructure.

    The success came from a year-long project designed to garner the lab a needed update to its ‘Authority to Operate’ (ATO) designation under the Federal Risk and Authorization Management Program (FedRAMP) for the new integration of Amazon Web Services across its IT infrastructure. The project successfully doubled as a pilot program for DevOps and continuous monitoring, says Ryan Kelley, systems engineer at NREL. He explained that the agency wanted to take lessons learned from staffers in a very limited separate department who had previously dabbled with AWS and DevOps practices and apply them for a fresh approach in a broader project within NREL.

    “The approach we took was, we’re not just going to try to jam all of our legacy toolsets into this and try to get them to work with the cloud,” he says. “We wanted to take a step back and say, ‘What’s the best approach for policy, what’s the best approach for toolsets and things like that for this new architecture?’”

    Part of the impetus behind this fresh approach was the lingering memory of how painful it was for NREL to gain its ATO five years ago. At that time the lab used outside consultants to shepherd it through the process and it turned out to be “extremely painful, drawn out and very, very expensive,” Kelley says, explaining that the ATO governs

    This time around, NREL hoped to find a way to use the expertise and resources it had in-house to streamline the process and not only comply with regulations but see a true return on its investment through a much improved infrastructure. According to Kelley, the project forced NREL to approach infrastructure almost like it was starting a new business.

    “We had a fresh slate and we kind of had to build almost everything policy-wise and everything toolset-wise,” he says, explaining that in order to comply with the security requirements around achieving an ATO, NREL was most concerned about what’s called customer-responsible controls, which are often very configuration-centric. “That’s where having a centralized configuration management system pushes you towards compliance because it’s just – it gives us that central place to audit all of our configurations. Out of the gate, to get cloud underneath our authority to operate, we needed the ability to centrally manage and have our configurations approved.”

    By approaching it as almost a new business, the IT team was able to make the cultural shifts necessary to achieve that through the improved teamwork and continuous delivery patterns that are the hallmark of DevOps.

    “Enterprise IT tends to think that they have to deliver these big, huge projects all at once and tied up in a nice bow, whereas we’re trying to take the approach of getting a minimally viable product and then rapidly iterating on it,” he says, explaining that it took about a year to get the ATO, but that NREL is still iterating to improve the cloud integration overall.

    Kelley says DevOps is providing a much needed shift for the organization due to the highly distributed nature of its programming resources. While the lab has a small cadre of IT staffers to run the backbone of IT infrastructure, the lab itself actually employs many programmers that actually work directly under what are essentially the lines of business for NREL, basically smaller sub-groups and departments working on individualized research projects. This ATO project showed that it is possible for the main IT group to interact with these smaller groups of developers to deliver quickly and effectively on projects and NREL plans to build on this success.

    “You know, we’re dealing with the same problems everybody else is: complaints that we’re too slow to deliver, not responsive enough, and not working with the business enough,” he says, explaining that past pundits’ warnings for IT to ‘align itself to the business’ never before offered concrete advice on how to do that.  “This was kind of one way that we did was just trying to find a project, develop a partnership and then sort of create a grassroots type of DevOps mentality.  It definitely wasn’t top-down. And we’re continuing to work with these groups in this particular manner.”

    Meanwhile, Kelley explains that the project also showed how continuous delivery toolsets can be instrumental in helping to with compliance demands.

    “We feel that these new modern toolsets that let you treat your infrastructure as code actually gives our cybersecurity team more insight into what we’re doing because once you do that and start treating it like software, then it can be audited a lot easier,” he says. “It’s a lot easier than building each server on its own and then waiting for security to scan it and then waiting for them to get us a report back and then we deploy it.”