devopsy.kinsta.cloud

Tag: security

  • DevSecOps: Critical in Building the Bank of the Future

    DevSecOps: Critical in Building the Bank of the Future

    It is no secret that change in a large organization can be difficult. This is often true within banking, an industry that often has sought predictably instead of agility in software delivery. However, with the right tools, guidance and teams, creating a bank that can be both complaint and responsive may be more attainable than initially it may seem. For a digital bank of the future to emerge from a heritage of independent application, information security and operations departments, an organization should embrace new technologies that can unify these groups and improve the ability to respond to change more quickly.

    Read on to learn why the inclusion of information security within DevOps practices can play a key role in establishing a bank of the future, and why it is important.

    Digital-Only Banks Gaining Ground

    One of the shifts in the distribution of banking products is the movement from primarily branch-based banks to digital-only banks. In fact, Citizens Financial Group launched a digital-only bank in July of 2018 to appeal to a growing number of digital-first customers. JPMorgan Chase also has a new digital banking offering, Finn, aimed at millennial customers.

    While digital-only is meant to simplify the end user experience, it complicates security because it increases the number of attack vectors within the digital channel. In effect, bank security is judged not by how well physical transactions are protected within the branch (think bank notes and checks), but how well digital transactions are protected over the internet. This can require a commitment of applying security controls while also honoring agile delivery practices. In turn, this developmental agility can be more effective when it is part of a responsive organization—one that is willing to adapt and adjust quickly, often requiring institutional culture change to an organization that is more transparent, open and ultimately innovative.

    Incorporating Security from the Get-Go

    To be more responsive while at the same time hardening security, adapting to DevSecOps methods is becoming important in the journey to be a bank of the future. DevOps should never be only about the development (Dev) build and operations (Ops) implementation—it should have security in the middle (Sec). Information security should play an integrated role in the full life cycle of apps. DevSecOps can remove the isolation and boundaries that previously existed between the security team and the rest of the organization, and it brings security smack dab into the conversation, rather than as a part of a deployment checklist. With service level expectations from release cycles going faster—from months to weeks or even days—integrating and automated security into the delivery process can be even more critical. In a DevSecOps application methodology, digital bank initiatives would build security into every touch point from the very start.

    How is Information Security Evolving in Banking?

    Banking, like all other aspects of our lives, seems, to be  transitioning to a smartphone transaction. Deposit and savings accounts can now be fully opened and closed through the digital channel. Information is exchanged digitally and the process is often painless. Information security becomes even more critical to help make  information safe and secure from potential fraudsters.  So while these types of transactions are often expected by consumers, it is important to have proper security measures in place and that can be fully automated and throughout the development process.

    The Organizational Change to Embrace the Future of Banking

    The future of banking will not happen exclusively just by changing technology and tools. It can often be successful when it is adapting organizational change at the same pace as technology and Agile best practices, such as DevSecOps, can also be applied to cultural transitions. To prepare organizations to be successful, there should be clear commitment by leadership across applications, operations and information security; otherwise, the change may never be fully absorbed into the organization. The bank of the future will be more likely to be successful if it functions as part of an ecosystem of interdependent and more securely connected people, processes and technology to have the structural support in place to successfully engage.

    — Eric Marts

  • DevOps and the Dark Pools of Security Technical Debt

    DevOps and the Dark Pools of Security Technical Debt

    We live in a world of digital transformation where organizations across industries are embracing initiatives around automation, cloud deployments and containerization of applications—and for good reason. Enabling transformative technologies such as DevOps, for example, can deliver superior product differentiation, faster time to market for new applications and services and an improved overall customer experience. A win-win, right?

    Not so fast. Amidst the explosion of new technologies, tools and practices, many business leaders are jumping in head first without testing the security waters, so to speak.

    In their race to move fast, it’s all too common for organizations to quickly realize that they’ve landed in a deepening pool of security debt that hackers are eager to exploit. As evidenced by recent breaches resulting from misconfigured AWS security settings, leaked S3 buckets full of secrets, database security misconfigurations, ransomware and the growing interest in exploiting CI/CD tools for hijacking IT assets to mine cryptocurrency, attackers are increasingly targeting DevOps environments.

    Security and DevOps Teams Swimming in Different Pools

    When it comes to prioritizing efforts, devoting attention to the non-functional requirements of DevOps infrastructure security often takes a back seat to the more observable value that the output of these systems provide. This is where security technical debt is created.

    Often times it’s a shortcut in establishing a process around managing security configurations, which is the first step on the path to an “event.” Other times it’s aligning personal development processes to corporate IT security standards.

    No matter what the first step in the chain is, the accumulation of unaddressed issues, incomplete process and failure to attend and improve security posture is how companies and groups find themselves in security quicksand.

    How deep and how wide is the security debt pool for DevOps and digital transformation initiatives?  Numerous studies show that most organizations simply don’t know what their level of exposure is, but there is concern about the unmet need of consistent security posture. We know this because security and compliance consistently rank among the top three barriers for DevOps and cloud initiatives year over year as evidenced in Puppet’s “State of DevOps Report” and RightScale’s “State of Cloud Report.”

    According to the “CyberArk Global Advanced Threat Landscape Report 2018,” fewer than half of DevOps respondents said DevOps and security teams are well-integrated, and 41 percent said security teams are only brought in at the end of the development cycle. These two departments are clearly working in different silos.

    IT security professionals and developers often have different areas of responsibility and focus on the DevOps adoption path. Owing to variable technical capabilities and operational silos, roles and responsibilities can get confusing, and the resulting work may or may not get done—leaving technical debt.

    While DevOps teams typically take ownership over application testing, QA and remediation for security flaws in software, there remains a significant “gray area” that isn’t wholly within the DevOps pipeline flow. For example, managing the security “of the pipeline” and adherence to the corporate standards for login ins/2FA and privileged account management, management of access control to secrets and rotation for shared sensitive corporate assets such as databases can impact other teams. Who builds and maintains these core controls for which the business needs to attest regarding the security of these systems when service level responsibility or operational controls are outside the DevOps team’s controls?

    It’s around these gaps that security responsibilities and operational roles get murky, and the debt pools deepen while issues remain unaddressed. The security maturity of various DevOps tools and open source projects vary widely. Missing security features as well as misconfigurations are to blame for numerous security events at many organizations with new stack components at work.

    As Cyberark Labs research has shown, DevOps pipelines can be starting points for lateral movement to other IT systems, so designs of isolation and containment are often aspirational rather than the actual achieved outcome. And for DevOps teams under tight deadlines, there are only so many hours in the day, and only so many additional items that can be added to the burndown list before something has to push and isn’t addressed in any given release.

    Breaking Down the Silos to Stay Afloat

    When these issues hit a breaking point, we see one of two outcomes: security gets involved too late and “puts the brakes on,” or the team makes a premature push to production of a transformative initiative resulting in a security event when the security process simply isn’t ready.

    When integrated and working toward common KPIs and goals, security can provide the extra bandwidth, focus and expertise to avert issues when they are brought into the process in a consultative role early, so called “shifting left.” Security needs to be built into development pipeline processes, and as we’ve seen with breaches of late, security needs to be a “feature” of the pipeline itself, which is the new attack surface cited above.

    Likewise, security teams must embrace new ways of working in the “fast-flow” of modern software engineering. They need to leave behind alarmism and “all or nothing” mental models, which were the security modi operandi of prior eras.

    Business level visibility to KPIs of success in integrating DevSecOps across the organization is often the missing link.  Whether it is red teaming the DevOps pipeline to raise awareness of the latent issues, or measuring security feature delivery success, measurement creates shared values of burning down security tech debt. Whether it is the most common security events by incident (eg. github hardcoded passwords) or the lead time to security feature delivery by the team, accountability insure attention to security success.

    In the end, it’s critical that DevOps teams work with security to ensure that speed, velocity and resiliency aren’t sacrificed for security. Every company’s fortune rises with the new value being created by digital transformation, but it can also fall with the reputational damage of a breach. Organizations need consistently aligned security and risk postures across all these new tools and technologies to reduce the pernicious pools of technical security debt.

    — Elizabeth Lawler

  • DevOps Chat: DevSecOps with ShiftLeft CTO Chetan Conikee

    DevOps Chat: DevSecOps with ShiftLeft CTO Chetan Conikee

    Security in the DevOps process has gotten a lot of attention lately, as companies grapple with ways to include security further up the application development process. The industry is still very much a nascent space, as players remain engaged in the security-versus-speed conversation—one always is sacrificed for the other. ShiftLeft, however, doesn’t believe that’s the case.

    In this DevOps Chat, Chetan Conikee, CTO of ShiftLeft, discusses his company’s approach to DevSecOps and how it can help keep the security department from being the “department of ‘no.’”

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone it’s Alan Shimel and I’m here for another DevOps Chat – DevSecOps related. I’m joined by Chetan Conikee, a CTO and cofounder of ShiftLeft. Chetan, I hope I didn’t mess your name up too bad.

    Chetan Conikee: Absolutely not, you did a great job. Thank you Alan, appreciate it.

    Shimel: Thank you. So Chetan, as I mentioned you’re the cofounder CTO of ShiftLeft – we’re going to talk a little bit more about ShiftLeft later in the show – but I wanted to start off talking about what is really one of the hottest topics in our world today and that is this whole whether you want to call it DevSecOps or DevOps and Security or Security Shifting Left – hence the name – talk to AppSec, some other people do – you know what about in your world? Are you seeing this kind of emphasis like never before on what some are calling DevSecOps?

    Conikee: Absolutely. Great question, Alan. Let me first start with the term shift left because it has two definite representations; one is a word and the other is a noun. Formerly ShiftLeft started as a way of doing things; meaning taking a practice and moving towards the left in order to reduce what they call as the meantime to repair. And that something could be testing or perhaps measurement of security as well.

    So when we adopted that name or changed the word to a noun we wanted to take this seriously; meaning how can we effectively build a product that can measure the security posture of another product at the left, informed from the right as well because often DevOps is nothing but a pipeline – an affective pipeline that is operating both at automation and high velocity. DevOps is all about taking code, building, packaging and thereafter deploying into your production ecosystem.

    But it doesn’t just end at deploying: it ends at measuring and feeding back how to optimize your systems thereafter. Often security does not fit well into this high velocity motion because most of the security products today are legacy or antiquated. These technologies like static analysis, dynamic analysis or perhaps a web application firewall finds it hard to fit into this streamline DevOps biplane. And I use that term emphasis with heart simply because these tools are producing outcomes and these outcomes are nothing but logs, information, alerts and all of this is sent back to humans in silos. And it is upon the human to figure out how to correlate this information and take affirmative action.

    So in essence this is impeding velocity rather than accelerating velocity, which DevOps is all about acceleration. As a consequence security gets left behind in organizations.

    Shimel: Can I tell you – I’m sorry – that was one of the best ones I’ve ever seen – one of the best definitions I’ve ever heard.

    Conikee: Thank you. Appreciate it. So we take this seriously as well because what we are trying to do is convert that definition into automaton, meaning how can you measure security thereafter quantify threats to vulnerabilities because often vulnerabilities are measures on the left, threats are measured on the right, so how can a human comprehend both these vectors, associate them and then address and fix these issues, because security is a huge concern these days.

    Shimel: Yeah. Agreed. So Chetan this brings up something I wanted to spend some time talking about here today and that is it’s a – not a survey but a study that ShiftLeft’s done – I think you guys had a partner on it – why don’t you share a little bit with our audience kind of just laying the groundwork there.

    Conikee: Absolutely. Today we are announcing the industry’s first real world benchmark of what we call a continuous application security solution. And in order to conduct this benchmark test we partnered and collaborated with Cobalt which is a leading provider of integration testing. They have some of the world’s best penetration testers working for them.

    So in order to conduct this benchmark test we submitted two instances of an application – a vulnerable application. By vulnerable I mean it essentially contains a certain set of vulnerabilities in it which we often test against in order to measure the efficacy of our platform.

    In this test we took that application and we deployed two instances in production. One instance was unpredicted: the typical instance that represents these vulnerabilities and have no protection applied to it. Whereas the other instance was protected by ShiftLeft’s one-time agent.

    So the premise of this test was to essentially let these penetration testers conduct tests against these two applications and thereby come back with results. And both these results had a certain degree of focus. The results were to identify what vulnerabilities can be declared by these pen testers upon the application that is not protected by ShiftLeft and thereafter subject the same set of tests on the application protected by ShiftLeft and come back to let us know whether they could penetrate that application or not, or perhaps could exploit that application or not.

    So this was a 14-day exercise and we defined the scope for this exercise – meaning what we essentially did was identified the most vulnerable or relevant applications called and racked by OWASP top ten and thereafter opened these applications to the Cobalt pen testers.

    Now as they began this exercise and Cobalt had hired essentially three white-hat hacking experts to attack both these applications. Cobalt was able to find and exploit all the six vulnerabilities in the unprotected application which is a validation for the fact that this was a beta application, it had the vulnerabilities and these exercises were successful from the pen tester’s perspective.

    Now they took that same exercise and applied it to the application protected by ShiftLeft and the outcome was they were not able to exploit any of those scoped vulnerabilities that we had described in the application.

    So the proof point for this exercise was to make ensure that ShiftLeft took the onus of protecting the application from any existential breaches or exploits applied by both potential white hats or black hats in the real world.

    Shimel: Got it. So fascinating stuff here. Talk to me now – so how – and forgive me and forgive our audience – we may not be knowledgeable about ShiftLeft – how does ShiftLeft in your company – not as the noun or verb here – how does what you do at ShiftLeft play into this Chetan?

    Conikee: Absolutely. Great question Alan. ShiftLeft is the industy’s first convert solution that seamlessly integrates into DevOps pipeline and protects the application by identifying its attack surface without reacting to threats. And let me explain what I just described in a moment.

    Often security solutions that have been thriving over the past few decades are built to essentially identify and understand exiting threats and thereafter protect the application. And by that I mean often when a threat is applied or an exploit is applied on the application that threat is published in public databases like missed CBEDBs and NBDBs.

    Then after all of these instruments that protect the application are validating every request applied on this application informed of the threat landscape. Now often threats have a lifecycle, meaning an attack or attacks an application by identifying potential breach paths. Now after they attack it is titled as an unknown vulnerability and when it is discovered it becomes a zero day vulnerability and thereafter when it’s published in a database it becomes a known vulnerability.

    Now note that often organizations are exposed in that journey from unknown to zero day known because it’s yet to be published. And for all these instruments that are protecting applications there is yet to update its policies to thereby protect the application.

    So we at ShiftLeft have devised a convert solution that first of all understands the applications evolving at that service. Now in the world of DevOps we deploy application multiple times a day, a week or a month. Now as the application evolves to serve a company’s business needs the application’s attack surface is evolving as well. It’s either heading in a positive drift or a negative drift. Often more times it exists or traverses in the negative side because engineers are coding at high velocity and when they code they don’t take security as a function into consideration.

    As a consequence attackers can figure out more creative ways to exploit the evolving attack surface of the application.

    So ShiftLeft has devised a technique that automatically processes byte code into the CI portion of the CICD of DevOps and extracts what we call is the attack surface of the application. Now from the attack surface we extract a policy: the policy that defines how to protect the application in one time because we do not want to feed these alerts back to humans and ask humans to correlate and address and prioritize these vulnerabilities.

    So in the spirit of respecting the fast motion of DevOps we extract the security profile from this attack surface and bootstrap an agent that is instrumented with the running application.

    Now the job of the agent is to act like one-fold full-time employee. The agent has taken the onus of identifying what is a potential imminent threat that is applied on the application by a black hat hacker and thereby understand better this particular track that’s taking this application into an inadmissible state because often attackers want to first take the application into a state that they wish to take it to and thereafter either exfiltrate data from the application or perhaps install some malicious payload on the host.

    So the job of the agent is to identify and segregate malicious intent and thereafter prevent that particular intent from manifesting.

    Shimel: Now Chetan I sit here listening to you – and keep in mind I have 20 years – 18 years in the ______ site space and I remember writing articles and papers on when is a zero day a zero day, when is it less than a zero day, you know, this whole discussion around what we can do to make our applications less vulnerable.

    And what amazes me is – I think we all agree, right, application security – at least for the last three to five years, maybe more – has really been at the forefront of cybersecurity research and so forth. And it’s only now that we’re starting to see solutions like ShiftLeft which are kind of not the same old same old taking a different view to an old problem or a different solution to an old problem.

    And yet, you know, I just got back from Black Hat – I’m not sure if you were there – we hear about one breach after the next and they’re still spinning money out of ATM machines. Are we finally on the right track to you think? Are we making progress?

    Conikee: Great question Alan. I would say that we have begun to make progress. You know, there is a journey, we have to embark on this journey and that journey means taking a practice and embedding into our typical pipeline – a pipeline of how we build applications, deploy applications and protect applications.

    So this is a beginning but a great beginning. But what has enabled this beginning is inspiration. You know often we learn from other systems and what I’m sensing is security is learning from DevOps. DevOps is all about automation, meaning before Amazon – the advent of Amazon or any public cloud like Azure or GC there was – the notion of provisioning a host took more than one step: we had to write a multitude of scripts in order to provision a simple physical appliance.

    And with the advent of companies like Chef Puppet and the public cloud they created this concept called this cloud formation; meaning how do you provision a virtual appliance in a matter of seconds and make it predictable thereafter? Because there is a system of record of your provisioning script and its evolution thereafter – that is one part. The other part is the predictability: how can you assess that particular script and understand its posture? Posture from a resource consumption perspective and resource provisioning perspective?

    Now if you take these two same principals to the antiquated world of security – and I use the term antiquated because in the past security was all about reacting to threats and alerts and then we had to deal with how to prioritize alerts because alerts can contain mixes of true positives, false negatives, false positives, et cetera. So how can we steal a page from the book of DevOps? How can we automate security? Meaning you’re creating code, from this code how can we automatically extract its security posture?

    Because in the world of security we are assessing code with three particular filters – or what they call SOSAs, sanitizers and syncs – SOSAs are where consumers interact with our application; sanitizers are where we are validating that input; and syncs are all communication points outbound from an application perspective.

    Often attackers are attempting to create new syncs after they successfully exploit the application. So how can we extract this particular fabric or script and thereafter take a security function into consideration?

    So this is our goal at ShiftLeft and we are hoping that this becomes a norm and other companies like us are adopting the same principal as well.

    Shimel: We can hope can’t we? But it’s interesting. You know I – what’s interesting Chetan is no developer raises their hand and says, “I want to develop insecure code.” No ops person says, “Boy, I want us to be the victim of a breach or have a security incident.” Nor does any security person say, “I hate the rest of the IT team so much that I hope they get hacked.” Right? None of this is true.

    But yet we have problems – and some of it granted is not just from a technology or toolset perspective, a lot of it frankly is cultural, right, as I’m sure you’ll agree as well. You know, and any time we could use tools that help foster culture, that help foster greater communication and teamwork – I mean I think we all benefit from it, right?

    And I hear a little bit with ShiftLeft, you know, this is something that I think is a byproduct if you will of your solution, is that true?

    Conikee: Absolutely. Well said, Alan. For the most part security should be an enabler rather than a department of no.

    Shimel: You’ve got it.

    Conikee: And security should – there should be a common lingua franca between various departments: meaning security, engineering, quality assurance and operations should speak the same language. The language should be comprehensible so that it becomes actionable.

    Shimel: Amen. Amen. You know, Chetan when we first started I think I mentioned to you the time goes so darn quickly.

    Conikee: Absolutely.

    Shimel: We’ve blown past our 15 minutes onto 20 here so we may have to call it an end but for people who may be interested in the recent study you did with Cobalt – and my friend Carolyn Long is a VP at Cobalt and she is one of the smartest people I know in security – where can they get more information?

    Conikee: Absolutely. Please visit blog.shifleft.io and on our blog we have a recently trending article that gives you the necessary detail about this exercise. And at the end of the article is the published benchmark’s test for those that want to delve into the detail – which I highly recommend – and thereafter visit www.shiftleft.io and – or contact us; we are happy to onboard your application and thereafter protect your application as well.

    Shimel: Fantastic. Chetan Conikee CTO co-founder ShiftLeft. Thanks for being our guest in this episode of DevOps chat and continued success with ShiftLeft – your success is all of our success.

    Conikee: Thank you Alan. Pleasure, and thank you for hosting us.

    Shimel: Okay. This is Alan Shimel for DevOps Chat. You’ve just listened to another DevOps Chat. Have a great day and see you soon everyone.

    — Alan Shimel

  • WhiteHat Security Looks to AI to Advance DevSecOps

    WhiteHat Security Looks to AI to Advance DevSecOps

    WhiteHat Security is now embedding artificial intelligence (AI) into the application security review services it provides, as part of an effort to advance adoption of DevSecOps processes.

    Joseph Feiman, chief strategy officer for WhiteHat Security, said the biggest resistance factor to DevSecOps has been the amount of time it takes to test applications for vulnerabilities. By injecting machine learning into that process via a suite of WhiteHat Sentinel Dynamic tools, which are being made accessible as a software-as-a-service (SaaS) application, developers will be more inclined to conduct security reviews as part of an integrated DevSecOps process, he said.

    The AI engine identifies vulnerability patterns in a code-based data lake of 95 million identified vulnerabilities that WhiteHat Security has identified via its dynamic application testing service (DAST). WhiteHat Sentinel Dynamic identifies known vulnerabilities in seconds, Feiman said, and any anomalies indicative of potential unknown vulnerabilities are then reviewed by human WhiteHat Security cybersecurity experts.

    Feiman said DevSecOps is going through a period of disillusionment because security reviews of code are taking too long. AI technologies represent an opportunity to reignite interest in DevSecOps by giving developers more control over an application security review process that no longer slows down development.

    In addition, WhiteHat Sentinel Dynamic enables developers to learn about their potential mistakes without necessarily requiring them to disclose them to the entire DevOps team. Any humiliation a developer might experience is avoided when the developer conducts the security review prior to committing code. IT security teams are still in charge of creating the policies that need to be implemented, but processes associated with implementing those policies make a decidedly shift left to the developer, he said.

    Feiman noted that the rise of AI within DevSecOps processes may help alleviate some of the current chronic shortage of cybersecurity expertise. There will always be a need for human cybersecurity researchers to train AI models what to look for as new vulnerabilities are discovered. But algorithms never take a day off or decide to abruptly quit because they suddenly got a better offer.

    It may take a while for IT organizations to completely trust AI engines to scan code for vulnerabilities. But currently many applications are not being reviewed at all because any time set aside to conduct that reviews is being eaten up by an application development process that has fallen behind schedule. Too many developers would still prefer to take a chance on a breach than be reprimanded for delivering code late, especially when there’s a chance to address vulnerabilities that might get discovered in the next scheduled release of a patch. WhiteHat Security is making the case for eliminating much of that risk by making it feasible for developers to quietly address vulnerabilities long before an application is deployed in a production environment.

    There’s no doubt that AI soon will be employed to automate large swaths of cybersecurity. But it may turn out that the most effective place to apply AI from a cybersecurity perspective early in the DevOps process as possible.

    — Mike Vizard

  • DevSecOps: Where DevOps and Security Meet

    DevSecOps: Where DevOps and Security Meet

    Catching up with three IT leaders on the role of security in the changing world of DevOps

    The DevOps methodology as a software and engineering culture goes back nearly 10 years—Patrick Debois coined the term when he named a Belgian software conference “devopsdays.” Since then, the movement has taken on a mind of its own, turning into the go-to strategy for enterprises the world over aiming to accelerate their development timelines and deliver better products faster.

    In the shifts and changes that have happened over the last decade, one has been the idea of “DevSecOps,” or the intersection where security practices and DevOps transformations meet. Recently, at the DevOps Enterprise Summit 2018 (DOES18) event in London, several key players in the DevOps world sat down to take a deep dive into the world of DevSecOps. In the following article, we’ll review some of the key points discussed by Ilkka Turunen, head of Solutions Architecture at Sonatype; Zane Lackey, founder of Signal Sciences; and Margo Cronin, senior solution architect for Amazon Web Services during our panel discussion at DOES18.

    The first point of the discussion centered around the role of security in DevOps, and how the name “DevSecOps” should never make you think security is secondary.

    “I’ve never been crazy about the term DevSecOps, because it’s like ‘Sec’ is an afterthought,” said Turunen. “You know, we were squeezing it in between Dev and Ops, the last kid that got on the bus, and we’re like, go on, just sit in there. For all of us, security is the first priority, the top job—’job zero,’ we sometimes call it. And therefore, for DevOps, it actually understands that security is key, and is the first thing that you do.”

    Turunen pointed to recent changes brought on by GDPR that have made privacy one of the pillars of software development, and how this has brought about further emphasis on security in DevOps transformations. In this new world of GDPR regulations, it’s not limited to just data portability and data breech notifications, but truly goes into “privacy by design.” As such, security is paramount.

    Later, the conversation turned to the idea of how one can create a culture where everyone thinks of themselves as a security practitioner, a seemingly necessary step to having foolproof security practices. The answer lies in creating an organization where security is part of the fundamental culture—a similar cultural change as to what happened around testing.

    “So if you think about testing 10 years ago, it was literally people running from test execution plans, and gradually they changed from that to becoming writers of tests, people that write the automatic-execution, help people, help the floor become more efficient at testing for themselves,” said Turunen. “Teaching them unit testing, all these other frameworks. So I feel like we’re at the brink of a similar kind of change. I think it’s a mixture of both incentives and psychology, and just changing roles.”

    Lackey puts it even more simply—that good engineering just goes hand in hand with good security.

    “The best way I’ve ever seen, like the highest performing organizations view it, is security is a subset of good engineering. In the way that resiliency is, reliability is, quality is, performance is, is a subset of good engineering,” said Lackey.

    Finally, the conversation turned to the role of public cloud service providers and how they can help uplift security for software organizations. For Cronin, the idea of machine learning holds a lot of promise for increasing security.

    “You now have services that can scan your landscape and say do you know these large files contain client identifying data, do you know you have keys there?” said Cronin. “And then you have services where you can then change that behavior automatically. But I think that’s where we’re going to see cloud service providers become a lot more active. You know, using machine learning to harden your production landscape before you actually even go to the security operators.”

    While the world of DevOps is constantly evolving, growth in highly regulated and compliance-oriented industries—coupled with increased global concern over data privacy—have put increased emphasis on incorporating security throughout the software pipeline. To learn more about how these DevOps experts view DevSecOps, and how they are making security a bigger focus in their organizations, you can watch the entire discussion on DevOps TV.

    Bonus: You can also watch Cronin’s DOES18 presentation on “Security Automation at Scale” and Lackey’s presentation on “How You Can Use DevOps to Make You More Secure.”

    And be sure to join us next time at DevOps Enterprise Summit Las Vegas, Oct. 22-24, 2018!

    — Alan Shimel

  • Defend Against Phishing Attacks with EV Certificates

    Defend Against Phishing Attacks with EV Certificates

    One of the most important elements of fishing is choosing the right lure or bait. The same is true when it comes to the malicious digital version—phishing. A phishing attack requires good bait to be effective. Organizations can defend against phishing attacks and help protect customers by using EV certificates to verify the authenticity of the website.

    Phishing Attack Targets

    Phishing attacks are designed to fool a victim into believing the phisher is a specific, trusted party for the purpose of stealing credentials, accessing sensitive data or propagating malware. The foundation of phishing depends on the ability to create a false identity that the target audience will believe is the real thing.

    The most common targets for phishing attacks are online businesses—specifically, online businesses where customers generally conduct financial transactions or share sensitive data. Businesses of all sizes from small “mom and pop” shops to large enterprises are viable targets for phishing. Businesses in pretty much every industry are potential targets for phishing attacks, but the most high-profile phishing attacks typically focus on banks, credit unions, investment websites, ecommerce retailers and other similar businesses.

    Creating a Credible Counterfeit

    Due to the way the web is designed and the nature of HTML code, it is trivially easy to counterfeit a website. A simple “screen scrape” is all that’s required most of the time. You can right-click and save most images, or just link to the original images and code from the site being spoofed.

    Voilà! The content inside the browser’s display window for a counterfeit phishing site can—and usually does—look identical to the content on the actual site. It actually helps maintain the façade of authenticity to leave legitimate links on the counterfeit site as well and only changing or redirecting a couple key elements.

    Avoiding Phishing with EV Certificates

    That’s where an EV certificate comes in handy. The attacker can scrape, download, stream or link to most—if not all—of the elements that are within the confines of the HTML window. However, there is no way for the attacker to re-create or spoof the green address bar of a website with an EV certificate. Because the EV certificate indicator is outside of the HTML window in the browser interface itself, it can’t be spoofed or counterfeited.

    Websites that have an EV certificate give users a clear and simple way to determine if the website is legitimate or a counterfeit. It’s a good idea for organizations to give customers the tools they need to recognize and avoid a phishing attack. In the absence of an EV certificate, people don’t have that same opportunity.

    Maximize the Value of the EV Certificate

    Aside from helping customers steer clear of spoofed sites and phishing attacks, a recent survey highlights the fact that people have more confidence and trust in websites that are validated with an EV certificate. To get the most value out of the investment in an EV certificate, though—and ensure that users benefit from it as well—you need to follow a few simple tips:

    • Use green address bars consistently on all customer-facing pages on the site.
    • For companies operating with multiple brand names, use the brand names on certificates that match the brands of those sites.
    • Proactively communicate to customers that your site has green address bars and what to look for (including images of what to expect in popular browsers)
      • Include this message on appropriate portions of the website.
      • Include this message in outbound communications such as newsletters and security bulletins.

    By communicating with customers what to expect when they visit your websites and what to look for to verify that the website is legitimate, and then universally using EV certificates that are consistent with the brand of the website for all public-facing sites, you can help customers recognize and avoid spoofed versions of your website(s).

    — Tony Bradley

  • VMware Extends DevOps Reach via SaaS Apps

    VMware Extends DevOps Reach via SaaS Apps

    VMware, at the VMworld 2018 conference today, announced it will be delving deeper in the realm of DevOps with the launch of a continuous delivery pipeline dubbed Code Stream.

    In addition, VMware announced Cloud Assembly, a set of declarative tools that enable IT organizations to spin up a cloud in as little as 10 minutes by managing infrastructure as code, and Service Broker, a catalog through which services residing on multiple clouds can be published, governed and secured.

    Milin Desai, vice president and general manager for the Cloud Services Business Unit of VMware, said these offerings extend the reach of VMware’s Cloud Automation Services that are all invoked as software-as-a-service (SaaS) applications.

    VMware also today announced a beta release of Secure State, a set of tools for tracking security alerts across Amazon Web Services (AWS) and Microsoft Azure that also can be used to investigate when changes to those environments were made. Secure Slate is based on the technology the company gained by acquiring CloudCoreo earlier this year. What’s more, VMware is updating the Wavefront by VMware monitoring service to add support for deeper support for containerized workloads running on Pivotal Kubernetes Service (PKS). Wavefront also now supports the Amazon Lambda serverless computing framework made available by Amazon Web Services (AWS).

    Code Stream is designed to track code across multiple platforms and comes with pre-built plug-ins for Wavefront, Harbor, Nexus, Pivotal Kubernetes Service (PKS), Ansible and Slack. VMware is also committed to providing integrations with continuous integration/continuous deployment (CI/CD) platforms such as Jenkins, Desai said.

    VMware has previously made extensive investments in software-defined data centers (SDDCs) based on a layer of management software deployed on top of VMware vSphere. As part of that effort, VMware today announced version 6.7 of VMware vSphere, which adds tools for verifying the state of a virtual machine, and a new Platinum edition of the platform that includes VMware AppDefense, to secure application workloads running on VMware vSphere.

    Beyond the virtual machine level, the scope of VMware’s DevOps portfolio has been limited. By adding a range of DevOps tools that are made available as SaaS applications, VMware now can provide tools spanning just about everything, from cloud orchestration to code delivery, Desai said.

    The expanded push into DevOps comes at a time when VMware is also extending the scope of its alliance with AWS. The company earlier this week announced it has lowered the cost of entry of VMware for AWS by 50 percent for a limited time and is making available a three-node configuration option. Previously, VMware required customers to set up a minimum four-node configuration. VMware will enable IT organizations to configure a three-host software-defined data center (SDDC) for the cost of two hosts.

    The company is further helping to reduce costs by make it possible for IT organizations to also specify the number of processor core counts for Oracle and Microsoft applications running on AWS, along with new options for deploying NSX network virtualization software.

    It’s unclear to what degree VMware will be able to leverage its historic strengths in server virtualization to become a significant force in the realm of DevOps. The acquisition of Wavefront in last year was clearly a significant step in that direction. But the individuals with an IT organization who decide what virtual machines to employ are not necessarily the same individuals selecting DevOps tools. VMware is clearly hoping that as more IT organizations embrace DevOps processes spanning multiple clouds, many more of them will view the company’s growing portfolio of SaaS applications as a natural extension.

    — Mike Vizard

  • Implementing DevSecOps in the Mainframe-Driven Enterprise

    Implementing DevSecOps in the Mainframe-Driven Enterprise

    DevSecOps is emerging as an important trend in corporate IT. It makes sense. With each passing day more applications serve a larger user base. Whereas in the past the typical business application was accessible only from within the confines of an enterprise’s internal network, today, the software-as-a-service (SaaS) paradigm enables millions of users work with a single application.

    In the SaaS paradigm, a single application will service a number of companies and give each user in the company access to data and functionality based on a given company’s subscription plan. Take Saleforce.com for example: There is but one Salesforce.com providing service to thousands of companies worldwide, each with one to thousands of employees. Each company and each employee within a company will have particular access rights to the application. A paradigm in which there is one application servicing millions, perhaps billions of users requires a comprehensive approach to security. The slightest breach can result in havoc. Imagine what would happen if a SaaS application contained a flaw that allowed a company to see the financial data of its competitor that also subscribed to the SaaS.

    Given that the internet is the de facto network for all worldwide, today’s security concerns go way beyond restricting network access. Keeping bad actors away is becoming more difficult all the time. The sad fact is that a seemingly good actor can turn into a bad actor instantly and wreak havoc not only on the servers with the network—as is the case of a DDos attack—but on the application layer as well. In fact, according to IBM, an enterprise’s network layer is half as vulnerable as the application layer, yet more money gets spent protecting the network.

    This is an eye-opening fact and one not on the minds of most application developers. But, it might be, if developers had the benefit of the expertise and ongoing guidance required to implement bulletproof security at the application level.

    Which leads us to the mainframe.

    In today’s world of modern, web-based cloud computing, the mainframe is a major player. Seventy percent of corporate data lives on a mainframe. Also, now that the Linux operating system is pervasive in the mainframe environment, enterprise-level application developers can—and do—write Java, Python and NodeJS code for the Big Iron just as they do for X86 commodity environments. Technologies such as IBM’s z/OS Connect EE and StrongLoop make it possible to use an industry-standard specification such as OpenAPI to expose mainframe services as REST API without a lot of low-level fiddling around.

    This is good news.

    The bad news that application developers are just not that adept at security best practices. They don’t have the experience of a CISSP professional who has spent years, if not decades, in the trenches battling the bad guys in cyberspace. But that was then and this is now. Today we have DevSecOps.

    DevSecOps is the next generation of IT transformation. The goal of DevOps is to create an IT culture that is unified, automated and self-correcting. DevOps combines development and operations into a single organization focused on creating and deploying quality software at ever-increasing rates. DevSecOps adds security into the mix. The scope of DevSecOps activity is not confined to software development for commodity-based X86 servers and mobile devices. DevSecOps is intended to apply across all facets of the enterprise, from mobile to mainframe.

    DevSecOps is about a lot of things. It’s about the adoption of tools such as IBM’s AppScan, a tool that allows an enterprise to implement and monitor a variety of tests (web, mobile, dynamic, static and interactive) in a unified dashboard. It can include leveraging Secure Service Containers to ensure external security and safety from insider threats.

    DevSecOps is about putting in place a set of policies, along with appropriate operational checks and balances, that ensure that the enterprise follows security best practices at all times. It’s about following practices that go beyond episodic security testing. This means continuously analyzing the IT infrastructure to identify vulnerabilities as well as defining ways to mitigate risks and prioritize prevention activities accordingly. It means making compliance to regulations such as GDPR, PCI-DSS, PA-DSS, ISO 27001 and ISO 27002, HIPAA, GLBA and Basel III  an enterprise-wide responsibility, not just something that’s siloed away to the Compliance Department.

    DevSecOps is about acting proactively by using automation to rigorously inspect all code to uncover potential hazards. It means using HTTPS as the default protocol for public-facing URLs. It means making sure that all third-party components are built from source code when possible—and, if building against source is not possible, ensuring third-party components and libraries are certified safe by an accepted authority.

    DevSecOps is about a lot of things, but there is one principle that overrides all others:

    When it comes to DevSecOps, the most important principle to follow is to make sure that a security expert is a starting member of any team involved with making software for the enterprise.

    It doesn’t matter if the company is 30 years old running on a mainframe or 30 days old using native cloud services, there must be security experts as part of its development work from the start.

    This may sound obvious, but it’s easier said than done.

    It’s not a new challenge. It took the enterprise a long time to get QA personnel involved at the start of development process. Before the DevOps/Agile sensibility took hold, QA personnel showed up at the end of the release cycle, well after code was hardened.

    The same is true of release personnel. Before DevOps, release management was given some code and told to just get it out as soon as possible. There was limited knowledge as to what the code was about or the potential impact it might have on the infrastructure. As a result, weekends were spent in war rooms struggling to deploy code that was sparsely documented and mysteriously tested. You can bet that once release management showed up at the first project planning meeting, things changed.

    Now, with the emergence of DevSecOps, it is security’s turn in the tumbler. Security has always been an important part of enterprise IT. The number of compliance regulations on the books attest to the fact. However, security was usually the responsibility of the Compliance Department more than part of the IT organization overall. For many companies, the only time security ever came to the forefront was during audit time. As a result, security practices were more reactive than proactive. And, for many companies, they still are—think back to reactions to the Equifax and Target breaches.

    However, the success of DevOps has not gone unnoticed. The standard features of DevOps—unifying groups toward a common purpose, implementing automation whenever possible and using sprints and retrospectives to facilitate fast releases and address shortcomings quickly—has had positive results. Forward-thinking companies understand that DevOps works, and its successor, DevSecOps, will work provided the essential principle is followed: Make sure security experts have a seat at the table from the beginning.

    For many companies this means transforming from a culture of isolated silos in which managers serve as gatekeepers and powerbrokers to one of unified open groups in which a manager’s job is to assemble self-directing groups and to make sure that all the right people are involved from the beginning of a project. It’s a fundamentally different way of doing business.

    When it comes to realizing the promise of DevSecOps, tools are important. So are processes. But, the most important thing is to make sure that security is built into the fabric of the development life cycle, from start to release.

    DevSecOps will fill the missing link in the software development chain. It has to. There is little choice otherwise. Adhering to the most important principle of DevSecOps—to have security involved as an equal player from the beginning of the process—will go a long way toward ensuring that all software, from mobile and IoT to native cloud installations and mainframe instances, will provide the degree of safety and reliability required to serve the needs of users and companies in the digital economy of the modern world responsibly.

    — Bob Reselman

  • Threat Modeling: The Why, How, When and Which Tools

    Threat Modeling: The Why, How, When and Which Tools

    You may have heard of threat modeling as a structured activity for identifying and managing threats. Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, IOTs and business processes.

    Threat modeling’s motto should be, “The earlier the better, but not too late and never ignore.” Without threat modeling, your security is a gamble—and in today’s business environment,  you’re sure to lose.

    When you design an application, you will face several security issues during different phases of the software development life cycle (SDLC), and so having threat modeling in the SDLC from the beginning can help to safeguard that applications are being developed, with security built in.

    Simply put, threat modeling is a procedure to identify threats and vulnerabilities in the earliest stage of the development life cycle to identify gaps and mitigate risk, which guarantees that a secure application is being built, saving both revenue and time.

    Why Threat Modeling?

    • It is better to find security flaws when there is time to fix them.
    • It can save time, revenue and the reputation of your company.
    • To build a secure application.
    • To bridge the gap between developers and security.
    • It provides a document of all the identified threats and rated threats.
    • It offers knowledge and awareness of the latest risks and vulnerabilities.

    How To Do Threat Modeling

    Many people think only security engineers can do threat modeling. That’s not true. Anyone, from developer to software project manager, can threat-model. In fact, I would suggest they should also know a little bit of threat modeling as part of their work.

    Let’s look at the elements of threat modeling:

    Assets: What valuable data and equipment should be secured?

    Threats: What the attacker can do to the system?

    Vulnerabilities: What are the flaws in the system that can allow an attacker to realize a threat?

    Steps to Threat Modeling

    Step 1: Identify the assets (database server, file servers, data lake stores, Active Directory, REST calls, configuration screens, Azure portal, authenticated and anonymous web user, Azure AAD client apps, database users, DB administrators)

    Step 2: Outline details of architecture on which the valuable asset is being processed. It may include the software framework, version and other architectural details (ASP.net web application connection to cloud data stores and third-party services using JWT tokens).

    Step 3: Break down the application regarding its process, including all the sub-processes that are running the application. We create a data flow diagram (DFD).

    Step 4: List identify threats in a descriptive way to review to process further.

    Step 5: Classify the threats with parallel instances so that threats can be identified in the application in a structured and repeatable manner.

    Step 6: Rate the severity of the threat.

    Threat Modelling Methodologies

    STRIDE (Uses application-centric approach)

    PASTA (risk-centric approach): Process for Attack Simulation and Threat Analysis

    TRIKE (risk-based approach with unique implementation and risk-modeling process)

    VAST (Visual, Agile and Simple Threat modelling)

    OCTAVE (focused on assessing organizational (non-technical) risks that may result from breached information assets.)

    When to use Threat Modeling

    In simple words, at the early stages of the SDLC, perform threat modeling:

    • Every time there is a change in the system’s architecture.
    • After a security incident has occurred or new vulnerabilities are introduced.
    • As soon as the architecture is ready.

    It is not a mandate to perform threat modeling at the early stages of the SDLC; you can still pick up threat modeling at any stages even if it is close to deployment.

    Threat models are continuously changing, and the models you prepared today may not be efficient tomorrow. And it is difficult to say that you are covered from all the threats. But if you have performed threat modeling and done whatever it takes to minimize your exposure to security risks, at least the impact of something very bad happening will be manageable (again, hopefully, but not a guarantee).

    Tools to Perform Threat Modeling

    I have used two tools for threat modeling, both of which are free to use.

    1. OWASP Threat Dragon
    2. Microsoft Threat Modelling Tool 2016.

    Let’s take a look at both the tools:

     

    Microsoft Threat Modelling Tool 2016         OWASP Threat Dragon

     
    Full version available for free (as of now) Alpha version available, flaws are still there. It is an OWASP incubator project, so it is at its early stage.
    Installable desktop application available. The tool comes in two variants: an online web application for GitHub and second an installable desktop application.
    Documentation easily available on Microsoft website. Default threat template is available. You have to search, default threat template is present
    I found the UX better, unique methodology available, the user can understand threats better. Guidance and feedback in drawing a model. Good UX. Fun and engaging user experience.
    Presently using this tool for threat modelling. Maybe I will use. I think will continue to improve.
    End-user documentation is available. End-user documentation is also available. Automated threats.
    Threat Grid, Template editor, Mitigating existing DFDs. Mitigating existing DFDs. Powerful threat mitigation. Rules have not yet been coded as it is the Alpha stage.
    Comes with a base set of threat definitions using STRIDE categories. Even in its current stage (alpha), you can create threats from those STRIDE categories.

     

    — Debarghya Pandit

  • DevOps Security: 3 Privileged Access Management Best Practices

    DevOps Security: 3 Privileged Access Management Best Practices

    The tremendous upside of DevOps practices and tools are enough to keep organizations pressing forward at all costs. But when sloppy use of DevOps toolchains cause breaches, more than half the time it comes down to poor protection of privileged accounts. According to a recent study by security vendor Beyond Trust, 52 percent of IT practitioners say that overprivileged users are at the root of DevOps and other next-generation technology-caused breaches.

    If organizations are going to reap the biggest benefits from DevOps without putting their IT infrastructure and data at risk, they’re going to need to think more strategically about how they handle privileged access management (PAM), said Morey Haber, CTO at Beyond Trust. devopsy.kinsta.cloud recently caught up with Haber to break down three of the most important PAM best practices for DevOps teams to build into the continuous delivery pipeline.

    Discover and Inventory All Privileged Accounts and Assets

    You can’t manage accounts and assets you don’t know about, so this step is foundational to the whole process of PAM. Unfortunately, with so many scripts and so much automation layered all over the DevOps toolchain, it can be tremendously difficult.

    “If it’s embedded in other runtimes or it’s hard-coded into compiled executables, that discovery is the hardest,” Haber said. But it must be done. Organizations need to get clear visibility into exactly what tools are executing the automation and what the privileges are assigned to them. “Is it a power-shelf script? Is it embedded in Jenkins or somewhere else? What is actually running? Who’s running it and when?”

    Additionally, organizations need to understand where the automation is stored and, consequently where that embedded credential information is being stored, so it can be examined for tamperability and safety of the credentials.

    “Now, this isn’t something that’s easy to discover in any of the three contexts, but it has to be,” Haber said. “So, one you have to understand the entire process and where you’re actually embedding privileged credentials for the edit, storage, operation and scripting itself.”

    Manage Shared Secrets and Hard-Coded Passwords

    Hard-coded passwords are one of the biggest no-nos in credential management. Unfortunately, even when application security teams are meticulous about rooting hard-coded passwords out of their finished applications, they often leave them within the IT infrastructure that helps support the development of that software for the sake of expedience. Same goes for account sharing, which is a frequent mistake organizations make to just get the automation working and keep it working with stability.

    The problem is, this trashes any semblance of traceability or auditability of activity within the affected environment.

    “Whether that is using some type of proxy technology, a VDI environment—anything, you don’t want people logging in directly with shared accounts because you can’t trace that,” Haber said, noting there needs to be a control plane in the mix that can keep track of both individual users and script or automation accounts that are impacting the environments to track each process or activity against unique credentials. This is essential not just for compliance, but for forensics and the overall integrity of a DevOps team’s software “factory.”

    Enforce the Rule of Least Privilege

    Ultimately, strong PAM depends upon only giving individual users or specific automation accounts the exact amount of privileges they need to get their job done.

    “We see credentials being given to DevOps teams all the time that are way, way overprivileged,” Haber explains “It should come down to the least privileged model—that you’re giving enough privileges for the DevOps process to work, but not overprovisioning so that if any process or account is compromised, it doesn’t jeopardize the rest of the environment.”

    — Ericka Chickowski