devopsy.kinsta.cloud

Category: DevSecOps

To Be or Not to Be – Shadow IT

Is it being an innovator, or demonizing business decisions to use other vehicles, and cry foul?

Sun Tzu, the famous Chinese strategist and philosopher, once said, “If ignorant both of your enemy and yourself, you are certain to be in peril.” These words ring true to the quandary that traditional IT organizations find themselves in today: on one side, hordes of tech-savvy business users are deploying and engaging technology services at an alarming rate, often without any input or validation by the IT team. On the other side, there’s an aging on-premise infrastructure that requires frequent care and stresses the limited resources and budgets of IT staff. In between, sits a group of technology professionals that want to support their users while maintaining the appropriate level of compliance, risk management and security — fondly known as “Traditional IT”.

Security teams, a part of traditional IT organizations, have begun demonizing any non-sanctioned technology use – dubbing it “Shadow IT – taking a somewhat close-minded view as to how software and services are being procured and utilized in today’s organizations. In the legacy world, IT Security could block or veto projects based on its merit and risk. Business teams had no choice but to work within their constraints, as the security teams controlled the firewalls — the proverbial gates to the kingdom. Nothing entered or left the organization without being blessed through the firewall, which left IT Security in a very advantageous position. Fast-forward to today and we see a drastically different dynamic taking place in organizations: DevOps and business teams are driving buying decisions, or making them without IT approval.

Why is this happening?

If you look at how various teams are structured in most organizations it becomes obvious. IT departments, a legacy construct best suited for organizations with few technology-savvy users, are best suited with a role as a service provider. Meaning, they build infrastructure, deploy software and services, and operate utilities as a service to their user base. This could be users in the form of bankers, call center employees, or even software engineers. There is no minimum or maximum level of technology expertise required on behalf of the user, because the IT department is there to offer support and guidance as necessary. This is very much a “thou shall not use technology not provided by IT” point-of-view, because IT is ultimately responsible for the support and user experience of said technology.

However, IT departments are fundamentally based around annual budget cycles and 3 to 5 year amortizations of capital expenditures (servers, network equipment, etc.). As the quality and variety of software, hardware and SaaS solutions has increased ten-fold over previous decades, we have quickly entered a buyer’s world where multiple satisfactory solutions can be obtained quickly. This is counter to the traditional IT pattern of planning purchases in advance, leaving ample time for procurement haggling. In as little as a year, entire service providers can spring up with scalable, resilient, superior technology solutions — often affectionately referred to as disruptors. These disruptive technology companies move fast, gather feedback from their customers, improve their product/service and deliver new products. If you just spent a million dollars on servers that you plan on keeping for the next three years, it is nearly impossible to justify leveraging a fleet of cloud servers as an alternative just a few months later. The cloud servers could be the right solution for your business — but the pain of wasted capital is too great for most organizations to shake, much less the implied defeat or mistake in judgment by IT management.

DevOps teams, on the other hand – and much to the chagrin of IT and InfoSec teams, thrive in the chaos of moving quickly and breaking from tradition. This is not done maliciously, but rather out of necessity to reach a peculiar and demanding audience. Years of “buy it now” instant gratification have conditioned the end-user to expect fast, high-quality and competitively priced products. This holds true for the Internet generation now responsible for the buying decisions of everything from inexpensive productivity tools to enterprise-grade communications solutions. Decisions are not made solely on who can deliver the highest SLA or who had the best benchmark score. Agile teams now look for the best product fit, defined by a set of conditions ranging from automation integrations to direction and vision of the vendor. This wide range of criteria falls well outside the traditional IT buying spectrum, and thumbs its nose at the legacy buying practices. DevOps teams buy subscriptions to services that they can change or cancel at any time. They procure products that don’t even have user interfaces beyond an API and JSON output. They buy based on “what can we do with this” rather than “what can this do for me”, which is reminiscent of maker culture.

A new breed of tools that enable the DevOps teams to do great things while catering to the IT Security team has emerged. DevOps teams tend not to budget for security, and are often too fast moving to build all the requisite capabilities themselves. IT Security is desperate for a place at the table to ensure the safety and security of organizations and its users. This sets the stage for new, emerging technology companies to capitalize on the widening gap that has occurred as the industry shifts from the traditional datacenter model to one of private, hybrid and public clouds. This means no more 3-5 year investments in a security technology and no 3-5 year guaranteed relationship for security vendors. Emerging companies also have to raise their game to meet the needs of these organizations and prove to be the partner of choice. The uptake to date has been slower as the industry has been slow to detect and understand this shift. Many organizations have legacy investments and don’t want to bring additional complexity to their lives by adding new panes of glass. DevOps teams may directly integrate raw data feeds from new products into their toolkit, but IT teams need solid integrations to existing infrastructure to make the best use of these new products. Without this, they can’t keep pace with the rapid deployments and changes made by DevOps teams, and are left nearly blind to the dynamism of their infrastructure risk and security posture.

So what is the solution?

It’s simple. By integrating security more deeply into the DevOps toolchain, and operationalizing security practices the same way we operationalize infrastructure and code issues. This means there is a space to not only bring cloud-centric data down to the legacy investments through connectors and integrations, but also an opportunity for IT Security to enable DevOps by automating common security practices. If the practices and behaviors of Security teams were operating at or beyond the pace at which DevOps teams deploy, then a collaborative environment can be built with security detection, notifications, and even mitigations act as a “safety net” in agile environments. This makes a lot of sense when you realize that the biggest threat to these agile organizations is not malicious hackers or state-sponsored attacks, but rather human error, policy failure, lack of transparency into security practices, and lack of consistency over time.

About the Author/Tim Prendergast

With well over two decades of experience pushing the limits of technology, Tim set out to create the first “next-generation” security company, Evident.io, focused solely on programmatic infrastructures (cloud). Tim co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level.

Tim’s prior experience includes leading technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee. He holds over 15 years of security experience; 8 years of AWS security experience, with 3 of them defending the Adobe AWS infrastructure from inception to production as an AWS Certified Solutions Architect.

Connect with Tim: LinkedIN | Twitter | Evident.io

February 25, 2015
Gartner’s dirty dozen worst network security practices

The folks at Gartner recently published a research note authored by Andrew Lerner and Jeremy D’Hoinne that highlights their dirty dozen worst network security practices for 2015. This is based on their interviews with over 3000 customers. I would give you the link to the report but it is not publicly available. However if you are a Gartner customer (and most of you probably are for good or bad) you can grab a copy of the report.

I have prepared by “Shimmy view” of these worst practices. I think many of them are right on. Have a look at the slides and let me know what do you think. Did they leave any out or put ones in that don’t belong there? One mans security worst practices is another’s best.

[seoslides embed_id=”194407f17459″ script_src=”https://devopsy.kinsta.cloud/embed-script/gartners-netsec-dirty-dozen-worst-practices/gartners-dirty-dozen/” overview_src=”https://devopsy.kinsta.cloud/slides/gartners-netsec-dirty-dozen-worst-practices/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Gartner’s NetSec Dirty Dozen Worst Practices” /]

February 13, 2015
Security Should Be the Top Driver for DevOps

I’ve often said that the driving factor for many companies in adopting a comprehensive information security program are the dreaded “F” and “A” words – FUD and Audit. Technically FUD is an acronym for fear, uncertainty and doubt. And it might be better said that audit is the action used to hopefully demonstrate compliance and trust.

Just a few years ago, the predominant drivers for security spending were regulatory and compliance requirements. While compliance remains a driver today, the primary moving force for many is the concern of cybercrime. Fear of being the next Sony, Target, Chase or countless other victims is driving information security budgets to be readdressed.

In a recent CA survey the top obstacle (28%) to DevOps in their organization were security or compliance concerns. Yet, in the same study, a huge percentage (88%) already have or plan to adopt DevOps in the next 5 years. The dichotomy of the situation has not escaped me. Organizations are in a situation where they are actively spending money on DevOps and information security, but at the same time view these two initiatives as counter.

The answer is simple, information security teams need to adopt DevOps principles.

While a widely agreed upon definition of DevOps is still up for grabs, its safe to say that DevOps is generally inclusive of a few core tools and principles. First, DevOps promotes a culture of cooperation and sharing among different groups in an organization. Second, DevOps promotes the use of heavy automation, decreasing time to market and agile development.

Information security’s goals are the CIA triad – confidentiality, integrity and availability. Security teams argue that DevOps is the antithesis of good security. Constant change, open culture and automation smack directly in the face of security’s tactics of compartmentalization and tight process control.

Here is a little secret – DevOps is winning, information security is losing.

DevOps teams are deploying code faster and faster. They are reducing time to market and increasing revenue. Information security teams, well, lets just say that they continue to be in the news for the wrong reasons.

The second little secret – the companies which are really winning are using DevOps tools and principles everywhere in their organization. Even in information security. Imagine overseeing infrastructure configurations with code that ensures compliance 24×7 across an entire organization. Or picture being able to instrument thousands of data points to benchmark security performance over time. Conceptualize being in charge of an automatic closed-loop security system which automatically takes action to mitigate attacks based on shared threat intelligence. These are possible with DevOps.

For all that DevOps provides, security should not be a hinderance to DevOps adoption. Instead, security should be a top driver for adopting DevOps. Using DevOps to create the next generation information security program might just be your only hope in combating the next cyber threat.

January 22, 2015
DevOps need to pay more attention to security

Ty Miller, founder of Threat Intelligence, suggests organisations adopting DevOps need to pay more attention to security.

Over the last five years or so, the prevailing approach to IT security has changed – largely triggered by the activities of hacktivist groups such as Anonymous and LulzSec – and it is becoming an increasingly integrated part of the application lifecycle, he said.

The less attention given to security in the earlier stages, the more likely it is that the application will have to be rearchitected and redeveloped before deployment, which can be 100 times more costly than building in security from the outset.

Since DevOps is often adopted to allow more frequent code releases, it is important that security is built into the process from start to finish, as there is no longer time for extensive security testing between completion and release.

Part of the problem is that developers tend not to be security experts, and because of their backgrounds security officers generally are not application security specialists. This can leave a security gap, he said.

Miller’s recommendations include:

Code libraries The reuse of known-good code instead of reinventing the wheel each time reduces the risk of building new vulnerabilities into software.

Platform security While IT teams would not dream of omitting intrusion prevention systems and other security components from an on-premises system, “these sorts of things are quite commonly being left out” from cloud deployments possibly because they are thought to be insufficiently scalable – a symptom of the tendency to sacrifice security for flexibility. And organisations sometimes assume that SaaS products are secure, even though they can “become large scale data breaches.” Recent research suggests around 90 percent of SaaS offerings are not sufficiently secure for enterprise use, he said.

Automated builds Automatically building systems based on pre-hardened templates helps reduce the risk of accidentally overlooking something and other human errors. If you can be confident that a new server will spin up in a secure configuration, development teams can concentrate on the code they are working on.

Automated security testing Frequent releases are at odds with traditional security testing, such as engaging specialist penetration testers before a major release. “That’s thrown a spanner into the works,” Miller said. When do you do the security testing? Can you pinpoint everything that has changed since the last test, and focus testing efforts accordingly? “Automated security testing needs to be built into the DevOps process,” he advised.

Fortify, AppScan and Burp Suite are among the more reputable tools, he said.

HP’s Fortify http://www8.hp.com/us/en/software-solutions/application-security/ , a code review tool, “is very expensive [at up to $120,000 per year] but also very good,” according to Miller, even though it generates false positives as other tools do.

IBM’s AppScan http://www-03.ibm.com/software/products/en/appscan/ helps with web and mobile app development, and costs around $30,000 per year, he said. While it has a good feature set and a convenient GUI, it does need a lot of setting up and maintenance when it comes to workflows.

PortSwigger’s Burp Suite http://portswigger.net/burp/ is a semi-automated scanner for web applications. At $300 per seat it is relatively cheap, and “virtually every penetration tester around the world uses it,” said Miller. It might not be as intelligent as the big-name commercial products, but “it is a very accurate scanner.”

But automated testing is not a panacea. Automated scans can find perhaps 20 percent of vulnerabilities, but that’s 20 percent less for humans to find. And the output of such tools tends to include many false positives, so some expertise is needed to interpret the results – an inexperienced user can waste a lot of time, Miller warned.

For example, access control flaws can be hard to detect automatically. Does changing a number in a URL produce a different page in the same report, or a report for a different customer? Is any particular report public or private? A penetration tester understands the application and can easily decide whether or not there is a security issue, but the best an automated tool can manage is to warn there may be a problem here.

An organisation that has a defined set of methodologies covering the entire process from development to production, implements security as a baseline feature in code and infrastructure builds, uses automated scanning and security testing, and integrates regular penetration tests and reviews “will be significantly ahead of other organisations,” Miller suggested.

About the Author:

Stephen Withers is one of Australia¹s most experienced IT journalists, covering everything from gadgets to enterprise systems. In previous lives he has been an academic, a systems programmer, an IT support manager, and an online services manager. Stephen holds an honours degree in Management Sciences, a PhD in Industrial and Business Studies, and is a senior member of the Australian Computer Society. You can see his Linkedin profile here: http://au.linkedin.com/pub/stephen-withers/0/222/687/

January 20, 2015
Webinar: Security & DevOps in 2015
The intersection of Security and DevOps. What does 2015 hold in store? Organizations are under increasing pressure to do more, faster. But cybersecurity breaches by criminals, hacktivists and state sponsored actors have cast a shadow over large portions of our IT infrastructure. How can security and DevOps in tandem make us safer while allowing us to increase speed and quality? This webinar features a panel of experts in security, development and operations. We will explore what this year and beyond holds in terms of help as well as pitfalls. What can you do to build more security into your processes? How can you be compliant, secure and efficient? This year promises to be a watershed in security and DevOps. Join us in this webinar to hear an expert panels views on what it means to you.

YouTube playback of the webinar:
Slides

[seoslides embed_id=”81ba77e9dda4″ script_src=”https://devopsy.kinsta.cloud/embed-script/security-devops-2015/4126/” overview_src=”https://devopsy.kinsta.cloud/slides/security-devops-2015/4126/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”security-devops-2015-webinar” /]

Date: Thursday, January 29th, 2015

Time: 1pm eastern standard time
```
REGISTRATION LINK:(CLOSED) 
```
About Speakers:

Moderated by devopsy.kinsta.cloud co-founder and editor-in-chief Alan Shimel, the experts on our panel are:

James Brown is Chief Experience Officer at JumpCloud. He works with the JumpCloud team to define product strategy, and set the overall usage and support experience. James’ background is in system administration, software development, security, and product management.

Tim Matthews is VP at Incapsula. Tim brings over 20 years of software sales and marketing experience at security and technology companies to Incapsula. Prior to joining Incapsula, Tim was CMO of CrowdFlower, the leading SaaS crowdsourcing platform. Tim holds a B.S. in Computer Science from Union College in Schenectady, NY.

Stephen Coty is Director of Threat Research at Alert Logic and also the author of the Cloud Security Report. In his role at Alert Logic, With his wealth of experience in the security space, Stephen is currently in the process of building a premier threat research team that is innovating the industry. He is also a member of ISSA, Infragard and the HTCIA.
January 19, 2015
Writing Security Acceptance Criteria into a DevOps Story

When organizations write user stories for development it should include the acceptance criteria. The acceptance criteria being a detailed description of the expected features and functionality the story should deliver. Far too often developers and product managers fail to include information security requirements as part of the acceptance criteria. Including security criteria in every story is a requirement of SecDevOps and rugged software development. I often get asked about what kind of security criteria should be included in a user story.

While not every user story needs to include a litany of security criteria there are a few basic rules one should follow that will go a long way in building a more secure and rugged application. Here are a few example categories of stories to consider requiring security acceptance criteria.

Input Validation

Most developers understand the importance of validating any kind of data input. Failure to properly sanitize and validate data has been the root of more kinds of attacks than any other method. Buffer overflows, cross site scripting and SQL injection are just a few of the more well known attack methods due to input validation failure. The bottom line when dealing with any kind of input data, especially that coming from an end-user, is simply never trust it – ever. Any user story that deals with input data needs to include acceptance criteria stating that the data needs to at least be sanitized and validated against the expected.

Storage or Transfer of Private Information

Before an organization can put controls around restricted information, they first have to define what is considered private by the organization. Start by defining what’s considered restricted. Data might fall into categories such as PII, PHI, IP, customer data or other. Any story that touches these classes of data needs to have information security acceptance criteria. Depending on how the company has chosen to protect, store or transmit this data will drive the story development and acceptance criteria.

Any use of Cryptography

There are a few basic, but important rules when it comes to cryptography. The first and most important rule is don’t invent your own cryptography. The second rule is to use a trusted and reputable cryptography library provider. The third rule is to only use cryptographic functions approved according to your company security policies. The fourth and hardest rule is to ensure you are using cryptography for its intended purpose. Keep these four rules in mind when authoring a story that has anything at all to do with cryptography and how they can be used to develop acceptance criteria.

Authentication, Authorization, Accounting

Authentication, Authorization and Accounting or often simply referred to as AAA is the heart of any access control system. AAA is the intelligence behind controlling access to resources, policy enforcement and auditing of said events. It might be better said that everything in AAA is information security related. When developing a story that deals with AAA, one should ensure the testing criteria include both the permit and the deny cases for the desire access matrix. For example, simply testing that a user can login with the right password doesn’t assume that a wrong password attempt will deny access. The other general point to consider is that AAA actions generally should include a log event for audit purposes.

Committing to develop rugged software is a key component of SecDevOps. Ensuring stories include security acceptance criteria goes a long way in moving security to the left in the development pipeline.

January 14, 2015
2014 – The year of identity security breaches

There’s no doubt that 2014 will be remembered in the IT industry as a year of major security breaches.

The year started with virtually every US resident worrying whether they’d been affected by the Target breach, and ended with the massive security breach of Sony and their film “The Interview.” And was, all along the way, peppered with other notable breaches.

The interesting theme, with all of the major security breaches, was that they were almost all related to compromised credentials. As we know, having the right privileged user management is one of the top ways to protect your network, you don’t want to share same hacker-limelight that Sony did.

But just for posterity, here’s a review of some of the top security breaches, and how they happened:

Target

What is considered the “biggest retail hack in history,” shook nearly every US resident in early 2014 as credit cards from 1,797 stores were compromised around Thanksgiving 2013. The hackers plotted against the company while Target was installing new security software. The repercussions were severe. Target reportedly spent $61 million on legal damages instigated by the breach, and profits fell by 46% in the holiday shopping season.

Suggested read: http://www.businessweek.com/articles/2014-03-13/target-missed-alarms-in-epic-hack-of-credit-card-data

Sony

Although the investigation into what occurred is still on-going, early accounts point to compromised user credentials (or even perhaps an inside actor providing credentials) being leveraged to access, gather and exfiltrate data. We know, of course, that the attackers gained a tremendous amount of data including unreleased films, personal emails, HR data, and other confidential documents. Bummer for Sony. The WSJ estimates the breach cost them $100 million.

Suggested read: http://techcrunch.com/2014/12/16/hack-sony-twice-shame-on-sony/

Celebrity iCloud Photo Hacking

While this particular breach was extra-sensationalized because of all of the celebrities involved, the Celebrity iCloud hack boiled down to plain old identity theft. Hackers identified email address, passwords, and the like and started gaining access to the iCloud data. Once in, they were able to copy all of the files. When celebrities realized they couldn’t login to their iCloud accounts, they naturally reset their passwords and were able to continue. Most of them didn’t even know they had been compromised.

Suggested read: http://www.cnn.com/2014/09/02/showbiz/hacked-nude-photos-five-things/

eBay

In late May, eBay notified its customers: it had been compromised. Credentials for employees with access to their critical systems were compromised, is appears, several months prior to their detection. Financial information, which was coyly stored separately, was not hacked. Lucky for eBay.

Suggested read: http://www.forbes.com/sites/gordonkelly/2014/05/21/ebay-suffers-massive-security-breach-all-users-must-their-change-passwords/

Home Depot

Over 56 million credit cards and 53 email addresses were stolen after a third party vendor’s employee’s credentials were stolen. This allowed hackers to gain access to the Home Depot network and make off with the confidential data. This breach was reminiscent of the Target breach in which another third party vendor (HVAC provider) was compromised and that subsequently led to Target’s compromise.

Suggested read: http://www.usatoday.com/story/money/business/2014/11/06/home-depot-hackers-stolen-data/18613167/

As you can see, the common thread to these security breaches is compromised credentials. Hackers realize the power of admin credentials in leveraging open systems. And, because many companies do an inadequate job of protecting their systems—despite patching, hardening, and firewalls—user admin access becomes an easy hacker target.

How can we stop this seemingly simple vector of breaches? Protect your credentials with good user management. Just patching isn’t going to get us there. At Jumpcloud we spend a lot of time looking at this, and ensure that security and user credentials are watched with close vigilance and best-practice security to keep hackers out. Drop me a comment if you have any other thoughts on this topic.

January 13, 2015
DevOps Connect: SecOps Edition @RSA Conference
We are very happy to announce that we will be hosting DevOps Connect: SecOps Edition at RSA Conference on Monday, April 20, 2015. It will take place at the Moscone Center and is sponsored by RSA Conference.

What is DevOps Connect? Great question. DevOps Connect is the new name for the Camp DevOps brand we have run here at devopsy.kinsta.cloud. We felt that Camp DevOps sounded too much … well, like a camp. DevOps Connect is so much more. We will hold DevOps Connect events at existing conferences such as this one at RSA Conference, as well as standalone events in cities around the globe.

DevOps Connect: SecOps edition will be focused on DevOps and security’s role in the software development lifecycle. The agenda, sessions and speakers will be chosen by our program committee. I am very happy to report that the committee is chaired by Josh Corman and Gene Kim, with the assistance of myself and Mark Miller, organizer of theNexus community. A formal call for speakers will be announced shortly.

We anticipate over 7 hours of sessions followed by the 2^nd annual DevOps wining, not whining happy hour brought to you by Sonatype, IT Revolution Press and devopsy.kinsta.cloud at a location to be announced.

Full details are on the DevOps Connect website, but there some bullet points:
1. Admission is free to all RSA badge holders, regardless of level. However you must pre-register for the event when you register for RSA Conference.
2. At the DevOps Connect website there is a code to save $100 dollars on an RSA Conference full conference pass.
3. We are limited to 600 attendees, so pre-registration is a must if you want to guarantee you are admitted. Attendance and registration is on and is on a first come first serve basis
4. Sessions will feature keynotes (Gene Kim will deliver one), panel discussions and multi-track topics.
5. DevOps Connect will be at Moscone West on Monday of RSA week.
6. Sessions and presentations will be focused on real world experiences from practitioners.
RSA Conference is where the premier infosec event in the world and we think a perfect venue for DevOps Connect: SecOps Edition. So if you are planning on attending RSA Conference you don’t want to miss what promises to be a great DevOps event!

If after visiting the DevOps Connect website you have any questions, please reach out to us at devopsconect@devops.com. We will update the website with more information as it becomes available.
December 8, 2014
Build security into your app development
Integrate security testing into your dev process now or else face cyber-attacks later

The way we develop software has been radically transformed in the last few years. Agility and speed are vital components for any company that wants to compete in the market. In order to achieve that it has proven necessary to break down barriers. The idea of separate silos with developers, operations, testers, and management working in isolation, sometimes even in opposition, is dated and flawed.

We’ve accepted the logic of bringing development and operations together with the DevOps movement. The recognition that testing is required earlier in the process has come. Now it’s time to apply the same logic to security. It’s time to bring InfoSec into the fold.

The security threat

Trends like cloud computing, big data, SaaS, and the BYOD end of the mobile revolution have created new opportunities for increased efficiency and productivity, but they also represent unique challenges for security. Sensitive data, financial information, and intellectual property are all exposed to risk when security is a secondary concern.

The issues that splashed back from the waterfall model for testing apply to security as well. Only passing applications through the QA process at the end of production, when time pressures to release were the greatest and it was too late to make significant changes, resulted in fixes being more expensive and software quality suffered.

If we don’t integrate security testing into the development process and make it part of the software development lifecycle now, then we run the risk of encountering exactly the same problem. We waste time retro-fitting functionality that should have been there in the first place, and we all know the pain of securing a hybrid system with legacy software that wasn’t designed with modern security threats in mind.

How to address security in software development

Automation for testing has enabled developers to move towards a continuous delivery system where new features can be rolled into live software as they are created. How do we ensure that security is maintained?
- Secure programming education is required to make sure developers are limiting and testing inputs, storing minimum data and encrypting, compartmentalizing the system, questioning requirements that may introduce security risks for little gain, limiting privileges, and analyzing and auditing the code.
- IAST (Interactive Application Security Testing) allows you to combine elements of static and dynamic techniques to run automated tests continuously on the software under development and see how it copes with malicious traffic. Since IAST monitors data inside the application it can pinpoint issues that might arise from real-world attacks, enable a useful assessment of the impact, and make it easier to remediate.
- Security analysts are needed to properly configure your tools and interpret the results. You can buy the best security tools in the world, but you have to know how to leverage them and act on the data. An external analysis can provide real insights that will boost application security.
- OWASP (The Open Web Application Security Project) is a great community where you can find innovative solutions to modern software security challenges. It can help you understand secure development standards and it’s packed with invaluable resources and advice from experts around the globe.
Bringing InfoSec on-board from the outset will help you build security considerations like this into your development pipeline. It will save time and money in the long term.

Ongoing research and modelling

It’s important to model potential threats and test for them, but you must be aware that new threats evolve and emerge all the time. Dedicated InfoSec employees will continually research and explore the new trends and risks in the security industry. Opening a direct line between DevOps and InfoSec enables them to pass along that wisdom and fold it into the mix when it’s relatively cheap and easy to do.

The security testing in your development pipeline is no more static than any other element. It has to be continually reviewed and modernized to ensure it continues to deliver results. Continuous real-time monitoring will deliver the oversight you need.

Building for the future

There’s no question that cyber-attacks will come, but if you prepare properly you can detect and nullify them with minimal effort. When considering the investment now, you must factor in the cost of lost confidence, post-mortem forensic investigation, and significant redevelopment to close any gaps in your defenses in the event of a future breach.

Once you have built solid foundations for security in your application development they will benefit every project going forward. Taking a long term view makes financial sense and results in better quality software.

About the Author

Michelle Drolet is founder of Towerwall, a data security services provider in Framingham, MA with clients such as Smith & Wesson, Middlesex Savings Bank, Brown University and SMBs. You may reach her at michelled@towerwall.com.
November 17, 2014
CI and CD Across the Enterprise with Jenkins – CloudBees
We are happy to announce the next devopsy.kinsta.cloud Webinar, in partnership with CloudBees :

CI and CD Across the Enterprise with Jenkins

Delivering value to the business faster thanks to Continuous Delivery and DevOps is the new mantra of IT organizations. In this webinar, CloudBees will discuss how Jenkins, the most popular open source Continuous Integration tool, allows DevOps teams to implement Continuous Delivery.

You will learn how to:
- Orchestrate Continuous Delivery pipelines with the new workflow feature,
- Scale Jenkins horizontally in your organization using Jenkins Operations Center by CloudBees,
- Implement end to end traceability with Jenkins and Puppet and Chef.
Date: November 19th

Time: 1:00pm eastern, 10:00am pacific
```
REGISTRATION LINK: (Limited registration, so don't wait!) 
```
About the Speaker:

Cyrille Le Clerc is Director of Product Management at CloudBees with more than 15 years experience in Java. Prior to CloudBees, Cyrille was Chief Technology Officer at Xebia. As an early adopter of the “you build it you run it” model, he put it in place for a number of high volume web sites. He naturally embraced DevOps culture. He is also very active in the Java community, creator of the open source project “embedded jmxtrans” and a speaker at various conferences.
November 3, 2014