devopsy.kinsta.cloud

Tag: application security

What Every Front-End Developer Needs to Know

One of the hardest things about being a front-end developer is the fact that everybody has very different expectations of what it means to be one. This, along with a technology stack that changes at the speed of light, makes interviewing for a front-end position tricky.

To help you out, and to give you an idea of our views on the role, we have prepared some points on what we consider to be essential knowledge for a front-end developer.

Be Able to Solve Problems

This sounds quite abstract, so let’s talk about what it means. Unlike many other developer positions, a front-end developer wields the power of multiple languages and technologies. Being able to look at a task, split it up into necessary steps and choose the right technologies for the job is an essential skill—some things need just a line of CSS, but implementing them in JavaScript would require a 100K library or vice versa.

Sometimes you won’t know the perfect tool for the situation at hand, and this is also fine. However, you are still expected to provide a solution. This solution may not be the nicest in terms of code quality or speed, but it needs to work—at least for the cases presented at hand.

JavaScript

React and Angular, along with other front-end frameworks, are quite impressive pieces of engineering and it is important to know them well if they are the primary frameworks you are using for the job. That said, knowledge of JavaScript, its core libraries and browser APIs will support you no matter which framework you use. Additionally, JavaScript is a general-purpose programming language, so doing some simple array or tree processing shouldn’t cause you any problems and shouldn’t immediately trigger the reflex to include that nifty 100k library that you would barely use.

One more thing to pay attention to is the asynchronous but single-threaded nature of JavaScript. You should be comfortable with scheduling pieces of work into the future in various ways and know how to execute some code after those asynchronous calls.

CSS

In the world of component-based frameworks and living style guides, you can get away with minimal CSS knowledge most of the time. Yet, when something goes wrong with your layout, or when you need to implement something unique, you need to know how browser layouts work. In short, we want you to understand CSS, but not necessarily keep all the flexbox properties or browser-specific hacks in your head—although it is certainly a plus if you do.

Know Thy Standards and Keep Up To Date

Nothing gives you as much appreciation of the complexities involved in making the front end work as reading the standards does: HTML, CSS and ECMA. It’s easy to get overwhelmed with more than 2,000 pages of quite dense and very specific reading, so start small. Websites such as SmashingMagazine, PonyFoo, HTML5Rocks and others will keep you up to date on the latest developments and might trigger an urge to understand things deeper.

Network

Every awesome front-end application needs to get to the user’s browser somehow. It’s also likely that you will have to make some asynchronous fetch requests to back-end services. All of this makes use of network, which means you should be aware of what is involved in making an HTTP request, at least on the level of Wikipedia with a sprinkle of cache-related topics, as well as what request latency is composed of.

While it is not a requirement for a front-end developer, knowing the connection on a TCP level is a nice thing to have, as is awareness of HTTP/2. Knowledge of REST services, at least from a consumer perspective, is certainly helpful as well.

Debugging

This goes back to the initial section on problem-solving, but also touches on every other front-end topic. Browsers are extremely complicated pieces of software with years of legacy, but still evolving at great speed, and this software is our domain as front-end developers. So whenever something goes wrong there, it’s our job to figure out why.

Sometimes it means looking for JavaScript errors, other times you may need to profile your code to check for slow code paths, and occasionally you may need to use CURL to fire off some requests from your terminal.

Security

Web, being an open platform, is constantly under the threat of various attacks, targeting both users and companies. Every piece of code and every call the browser makes is a potential source of security vulnerabilities—initial load of the page, AJAX request, external scripts or iframe, and even a simple DOM manipulation can be vulnerable to XSS, CSRF and various other vectors of attacks. Being aware and vigilant is an essential requirement for the safety of the data of your customers and your company.

Testing

QA, as a department or a position, hasn’t existed at Zalando since we brought in Radical Agility in 2015. We believe that it’s each developer’s responsibility to ensure the quality of their produced code, and front end has some very specific strategies for testing and asserting non-functional properties of the code.

We believe that unit testing is a must for any project, and we highly encourage TDD, especially for a dynamic language such as JavaScript. Generally, you also would want to supplement this with some end-to-end or functional tests to make sure users can do what we expect they should be able to do.

Tooling/Automation

All of the topics discussed here also require very specialized tooling. You definitely should be comfortable with the concept of resource bundling and the tools available for this purpose. As mentioned above, testing by hand is not our thing, so a setup with automated tests is a must for every project.

Ideally, tooling and automation should be complemented by continuous integration/continuous delivery to make sure no code slips past without running those tests. Depending on the project, you also might want to use a transpiler such as PostCSS or Babel to help you write more modern code.

Conclusion

What we’ve collected above is obviously an enormous amount of knowledge and will rarely exist in a single mind; however, the strongest candidates have at least a general understanding and a keen insight with a select few to stand out as a front-end developer.

About the Author / Dmitriy Kubyshkin

Dmitriy Kubyshkin is a front-end architect at Zalando SE, helping delivery teams with the migration of their front-end features from a legacy monolith to their new microservices architecture. Connect with him on LinkedIn / Twitter.

October 11, 2016
It’s All About the Tools: Lifecycle Security and Testing

In the past, whenever a new application or a new version of an application was bought to market, users often were abused as beta testers for security and usability. This was largely because of a lack of opportunity to test a large codebase effectively and efficiently.

Similarly, the subsequent patches and new applications versions were rolled out with minimal testing, often fixing the existing bugs but introducing just as many new ones. Because users didn’t know there was an alternative, they accepted this situation grudgingly, and the consensus formed that there was no such thing as bug-free software.

Today’s users are much less tolerant of bugs, particularly when those bugs are security vulnerabilities in hosted applications. Nowadays, anyone offering an application online rarely has to wait long for hackers to examine the weaknesses, which, for suppliers, means the integrity of their own networks are at stake. Finding these security weaknesses in e-commerce applications or online booking systems, for example, is highly attractive to hackers because of opportunities for identity theft or to issue ransomware that may damage the company’s sustainability.

Hackers don’t just target the obvious bugs in applications. Distributed Denial of Service (DDoS) attacks increasingly are aimed at an application rather than the network infrastructure, often making the application unavailable to legitimate users.

Developers need to ensure they understand the importance of security and load testing over the application development life cycle. To deliver more secure products to market, it is essential to identify the aspects of development that can harness security faults and address these challenges with the time and financial support of C-suite and IT executives.

Lack of Time for Security Testing

Security defects must be avoided as much as possible. This requires intensive testing and the right tools. Time is precious, and time-to-market often is a critical success factor for new applications. For IT decision makers, it’s necessary to balance these security concerns and time pressures with an organization’s appetite for risk and its allocation of resources.

In addition, IT leaders and developers need to look at the effectiveness and agility of their security testing. Agile software development decreases the period between software releases from months to days or even hours. It is widely acknowledged that the classical iterative, develop-test-develop process for troubleshooting takes too long, so it often is overlooked. As a result, security defects often still find their way into software versions and must be eliminated later, which drive costs higher. For example, according to the National Institute of Standards and Technology (NIST), the cost per defect in the development stage is US$80, but quickly jumps to US$960 per defect in the testing stage and US$7,600 in production. NIST estimates that these costs amount to almost US$60 billion annually in the United States alone.

Developers are widely aware of the growing challenges with security testing. In a recent Ixia survey of 363 developers, a clear majority of respondents nominated security testing as the most critical component of the development cycle. In fact, 93 percent report they subject their applications to security testing during the development process early, and continuously. And yet, two-thirds of the respondents admitted to delivering products with bugs and/or security flaws. Whether this is because of a lack of time, appropriate tools or financial support, this can put application security and functionality and an organization’s network at risk. Subsequently, eliminating these defects with patches or updates is at least four times more expensive than addressing them during development.

Test Early, Often and Under Real Conditions

A range of comprehensive security testing solutions are emerging to integrate security testing more closely with the development cycle. These solutions give developers powerful and comprehensive test environments to monitor application behavior carefully in response to DDoS attacks, malicious traffic and automated attacks, which lets developers identify bugs or vulnerabilities at the encoding stage. These tools also generate realistic traffic for load and safety tests to simulate a wide range of protocol mixes and traffic patterns. In addition, these solutions include development tools such as integrated debuggers that import and replay recorded packet captures.

By using REST APIs and a rich command line interface, these integrated security testing solutions work with a range of continuous integration/continuous deployment (CI/CD) frameworks. These agile CI/CD frameworks streamline discovery and resolution of issues found in different phases of the application development life cycle.

These solutions also streamline communication and reporting within multifunction teams via a range of community features such as referrals, real-time feedback and task allocation. Using a completely virtualized solution also lets developers improve security testing across the application life cycle while minimizing any hardware or infrastructure investments. Plus, the agile CI/CD model helps disparate teams across the service provider—QA, production, development and vendor collaborate effectively and streamline discovery and resolution of issues found in different phases to accelerate the time to market.

The ability to increase the development team’s agility and speed while improving application security is making many IT decision makers sit up and take notice. With company boards requiring IT departments to respond more quickly and effectively to technology opportunities, IT leaders are seeing the benefits of this new way of working that combines the twin priorities of agility and security.

Developer teams should communicate clearly with IT executives to secure the required time, money and resources to ensure new applications and updates undergo rigorous and realistic tests before they are released to market to face the mercy of hackers. Using commercial tools and systems for security and load tests help to determine the behavior of applications under different stress loads. They also help developers deliver products to market in a more cost-effective, timely and agile manner.

About the Author / Phil Trainor

Phil Trainor is Head – Security Business, APAC at Ixia. Phil has worked in the network security industry for 14 years holding senior level engineering roles at California-based startups. He was recently a guest lecturer at the 2016 RSA Conference in Marina Bay Sands discussing ‘Advanced Persistent Threats’ and has also lectured at Blackhat, DefCon, ToorCon, and at many other prestigious security events. Connect with him on LinkedIn.

September 6, 2016
The 2016 State of Software Supply Chain Report is Here
Our State of the Software Supply Chain Report has just been released. Over the past year, we’ve amassed a great deal of data with respect to the staggering volume and variety of open source components flowing through software supply chains into development environments. This year, we assessed behaviors across 3,000 organizations and performed deep analysis on more than 25,000 applications.

The results we discovered ranged from staggering to surprising to sobering. For example, we measured organizations consuming an average of 229,000 components annually. The good news is, these components help companies accelerate their development and innovation. At the same time, we saw 6.8% of components used in applications marked with at least one known security vulnerability — adding high levels of security debt. Not all components are created equal.

Software supply chain infographic from 2016 report. See full image here.

The 2016 State of the Software Supply Chain Report blends public and proprietary data with expert research and analysis to reveal the following:
- Developers are gorging on an ever expanding supply of open source components. Billions of open source components were downloaded in the last year.
- Vast networks of open source component suppliers are growing rapidly. Over 10,000 new versions of open source components are introduced daily.
- Massive variety and volume of software components vary widely in terms of quality. 1 in 16 parts include a known security defect.
- Top performing enterprises, federal regulators and industry associations have embraced the principles of software supply chain automation to improve the safety, quality, and security of software.
We invite you to read the report and leverage the insights to understand how your organization’s practices compare to others. Then, let us know what you think @sonatype.

If you would like to join a live discussion on this year’s report, please join us on Wednesday, July 13th. Save your seat here.
July 11, 2016
Rugged DevOps: Less Capture the Flag, More Teamwork

At the recent DEVNEXUS conference in Atlanta, I caught up with Chris Corriere to talk about his experiences in the realm of Rugged DevOps. Chris is a DevOps Engineer at AutoTrader and a contributor here at devopsy.kinsta.cloud. During our conversation, we discussed automation, culture and collaboration, and which thought leaders he is following. Chris also shared insights on the upcoming DevOps Days Atlanta conference where he serves on the organizing committee.

Derek Weeks: What’s your definition of rugged DevOps?

Corriere: Rugged DevOps to me is definitely manifested in the security sector but it’s a shifting quality and awareness left in doing the best we can with the tools we have, the constraints we’re given, and in the environment we’re in. It’s about being more experimental, understanding that we’re going to encounter failure, and learning to adapt accordingly. We’re very much having to make tough decisions in real time. If you’re running anything in production these days, you need to do that as safely and as consistently as you can.

Weeks: Is rugged DevOps only about security?

Corriere: No. Security is really about mitigating risks. I think a lot of this ties into situational awareness about understanding your company’s risk. Is it user data? Is it credit card transactions or do you have a Russian botnet running in your infrastructure that you’re not aware of? What’s the asset you need to protect? Are you trying to protect an asset that is not there?

You can’t have security come in and become suffocating where it’s not needed. In other situations you can’t leave things wide open that really do need to be protected because you’re more concerned with moving quickly than moving safely.

https://youtu.be/fgMPKkM1NdY

At the end of the day when you’re mitigating risk, it doesn’t matter if it’s customer data or a broken build or a bad user experience, these are all risks we need to mitigate. That’s really what rugged DevOps is. It is about is tying that value back to the user. It’s knowing what problems we trying to solve and understanding what we doing effectively (or not). It can be locked down as tight as you please, but if you cannot use the tool to solve the problem you picked it up for, it might as well not be running.

Weeks: Security teams have been one of the last parts of the organization to come into DevOps practices. What’s been your experience with engaging security teams at Auto Trader?

Corriere: That’s a good question. I’ve had experience with more than just security teams at Auto Trader. I’ve been involved in security a few places and they’ve approached me first when they found out I was into the DevOps stuff. They often come looking for assistance. They want to know: How do we get this baked in? How do we make this a priority?

It really ties back into multi-factor authentication. It’s a good way to frame it up where you want developers and operations (those people who aren’t permanently rooted in security) to be aware of these things, to have automated scans, to be aware of cross-site scripting, and to understand how to remediate those kinds of issues.

We’ve been implementing open source tools earlier in the development lifecycle to give us quicker feedback loops in order to be able to triage these things. Security applauds that but they can’t trust us too much with it. They’ve got to verify that we’re doing a good job with this, right? It’s a give and take where I’ve seen security come and offer automated solutions to DevOps teams and those solutions get adopted. The DevOps teams then take that and really start to run with it. Then security wanted to slow down a little bit because they were concerned about the quality of the vulnerability remediation. There is some back and forth there that has to be anticipated.

________________________________

“We’ve been implementing open source tools earlier in the development lifecycle to give us quicker feedback loops.”

________________________________

For security to trust you you’ve got to trust security to a large extent. If you’re putting more automation into the left side of your process and doing things before they hit production should be making your job easier. One of the side effects of that security may start going through some systems with a finer tooth comb because they’re not doing as much fire fighting. That may result in another ask from security. Understanding that this isn’t a declaration of war—we are simply continuing with an incremental progression toward further improvements. Interactions are cyclic and will happen again.

We need to help security understand our pipeline, determine what’s going to be a good fit, and keep that communication level high so the trust is there. In these symbiotic relationships, cooperation is dependent on that trust. If that trust goes away you end up in something more competitive.

There’s always room to drop back to where it’s more commensal and knowing when the kitchen’s gotten too hot. At those times, everybody needs to take a cool down lap and come back to it at the beginning of the next month. It goes back to that situation awareness, knowing where you’re at right now before you try to get to where you’re going.

Weeks: We talked earlier today about red teams, blue teams, purple teams. What are they and can you describe some of the practices you’ve used to end up with more purple teams?

Corriere: Yeah. Red teams take an attacking, reactive posture. Red security teams are worried about internal compromise, and when they find gray areas—for example, things that haven’t been fully signed off and authorized—it can result in unplanned work cropping up for the DevOps team. Generally that kind of unplanned work is introduced because the “Red” team felt they were not able to accomplish their job another way.

Then the blue team side of the equation is really trying to stomp all that out. Blue teams keep things standard and locked down. They make sure everything’s approved in triplicate before it gets implemented, which can be rigid and very frustrating for developers.

Purple teams allow that experimentation in earlier in the development lifecycle where they’ve got a little bit more leash. They’re allowed to experiment and stand up new things and make those things work before they getting it approved. Again, it’s about being transparent. Teams first want to understand what change was introduced and what the advantages of it are. They may also acknowledge that you need more than one solution to some problems, and that one tool might not fit everybody. If they’re using tools to automate that’s good. We can’t box them all into one necessarily. That’s where you see this go from blue and red to more of a purple. There’s more communication. There’s more conversation. There’s less capture the flag, more teamwork.

________________________________

“There’s more communication. There’s more conversation. There’s less capture the flag, more teamwork.”

________________________________

Weeks: You’ve been involved in the conversations around rugged DevOps for awhile. Who are some of the other thought leaders you learn from?

Corriere: Jamesha Fisher out of San Francisco is one. She’s done some neat security stuff and is starting to look more into the vulnerabilities around some of the automation tools. Where are those vulnerable and where can they be leveraged against us? Automation is great until it automatically starts doing things we didn’t want. Another aspect of that is really trying to think more like an attacker; we need to think about: how would I break into this thing instead of just thinking how do I protect it.

Georgia Weidman is popular in a lot of security circles and I’ve missed her workshop once. I’d like to catch it. She’s got a book out on pen testing which covers a lot of operations and concepts from an attack perspective. I would say that can be a fault of some rugged DevOps practices; you’re so quick to get the thing working and provide business value that you don’t realize where you’ve left something vulnerable. Sometimes you’ve got questions about why that thing you work with frequently is always locked down. Perhaps you find you can’t use it the way you want to. At those moments, it’s time to read through Georgia’s book. You’ll get some information as to why that thing is not open the way you want and where someone might use it for reasons might not expect.

________________________________

“You’re so quick to get the thing working to provide business value that you don’t realize where you’ve left something vulnerable.”

________________________________

Weeks: As we wrap up I know you’re on the organizing committee for DevOpsDays Atlanta. Do you want to give us an insight on the dates of when that’s coming up and call for papers, et cetera or we can help you share that?

Corriere: Our CFP is open through the first of March. Our event is going to be in April. It’s the 26th and 27th which is a Tuesday and Wednesday. Monday, the 25th of April, we have Jeff Sussna coming in to do a full day workshop on continuous design. He’s going to be giving the keynote on our first day. We’re excited to have Jeff in town and excited to have him as a keynote. John Willis is going to be giving our keynote on the second day.

We’re looking for proposals from anything in progress, people learning in the field, or trying to drop that barrier of entry. We’ve got a lot of bright people in the space. We’ve got a lot of people learning as they go. We need to be more vocal about that learning process and how we find our way through it. There’s not always this instantaneous vision that strikes us. We understand how to convert a shop into continuous delivery every night. There are definitely steps in between that. We need to have more conversations about those step in our industry. Yeah, anywhere in the stack, any interesting projects going on, we’d love to hear from you if you’ve got something.

If you are interested in learning more about this subject, I invite you to download Amy DeMartine’s Forrester research paper, “The 7 Habits of Rugged DevOps.”

As Amy notes, “DevOps practices can only increase speed and quality up to a point without security and risk (S&R) pros’ expertise. Old application security practices hinder speedy releases, and security vulnerabilities represent defects that can leave a company open to cyberattacks. But DevOps practitioners can leap forward with both increased speed and quality by including S&R pros in DevOps feedback loops and including security practices in the automated life cycle. These new practices are called Rugged DevOps.”

February 24, 2016
Case Study: Pearson Weaves ThreadFix into AppSec, Part 2
In part one, we discussed how education content publisher Pearson applied ThreadFix to its AppSec request workflow needs. Here’s the rest of the story.

The ThreadFix Implementation

Senior software security engineer Matt Tesauro added ThreadFix to Pearson’s workflow in the following steps:
1. Using FPM, Tesauro created a Debian Linux package internally to deploy the ThreadFix Tomcat Package (ThreadFix also offers its own Debian package for this).
2. Tesauro hooked ThreadFix into each of Pearson’s toolsets using the tool scanner file formats ThreadFix understands.
3. Using the importers built into ThreadFix, Tesauro connected it to the Checkmarx, Veracode, BurpSuite, ZAP, WhiteHat, AppScan and Qualys testing tools Pearson uses.
4. To make that happen, Tesauro pointed ThreadFix to an API.
5. Tesauro then set up an API key.
6. The system was then set to fetch the test results.
7. If necessary, Tesauro wrote glue code to upload the results to ThreadFix.
Pearson used ThreadFix to normalize and de-dupe what had proceeded from manual assessments, dynamic scans on applications and static code analyses of source code, directing those outputs into ThreadFix. “So if a static tool and a dynamic tool both found the same cross-site scripting issue, we fed those into ThreadFix, which de-duped those and gave us just one issue to report so that we didn’t bury two teams with fixing the same single coding error,” says Tesauro.

“ThreadFix became the one source of knowledge for all of the output of our team, which for us is the security vulnerabilities we find in the applications that we either created, bought or had a third party create,” says Tesauro. That enabled Pearson’s AppSec team to feed tickets into JIRA of backlogs from development teams, which made it easier to produce metrics and do reporting. ThreadFix made it easier to feed data into governance, risk, and compliance tools such as RSA Archer. “That enables visibility into work in progress and workflow and into areas of the business that affect AppSec’s work,” Tesauro notes.

Additional Capabilities with ThreadFix

Tesauro eventually expanded ThreadFix to other departments beyond AppSec to benefit from its capabilities and the metrics it could produce regarding app progress.

Tesauro notes a point between the “Bag of Holding” and ThreadFix in the AppSec pipeline that required some work. He used a StackStorm orchestration and layered ChatOps on top to enable new developer capabilities at that point in the process.

“Now you can go into our private channel and use HipChat to ask the system, for example, to set up Checkmarx for a particular application in a particular business unit. You give it the URL pointer to that unit’s Git repository and off the system goes, setting up the application profile in the Bag of Holding and in ThreadFix and then talking to Checkmarx to set up weekly scans of the code that sits on the master branch. It set that all up in a minute,” says Tesauro.

HigherEd was the first additional group inside Pearson to benefit from ThreadFix metrics. One such metric was a 44 percent decrease in time-to-fix after adding a JIRA integration into the mix, according to Tesauro. “Once we started producing those numbers, we had a lot of other business units ask, ‘Hey, why does HigherEd get these great time-to-fix numbers? We want them too for our apps.’ It was a great way to get buy-in,” says Tesauro.

Further Results

AppSec saw a 5x increase in throughput for the request workflow and went from 44 application assessments in 2014 to fewer than 200 in 2015, Tesauro notes.

“In 2015, we lost two and a half people and still sped up the process,” he says.
February 15, 2016
Case Study: Pearson Weaves ThreadFix into AppSec, Part 1

Pearson is a publisher of education industry content to meet the needs of teachers and students from kindergarten/early learning through higher education and continuing education (for professionals). The company uses a mix of software, from legacy third-party software and “classic ASP apps that are on life support to auto-scaling systems on Amazon,” says Matt Tesauro, senior software security engineer at Pearson. “It’s a very diverse development environment.” Which meant it was no easy task keeping it secure.

Pearson Before DevOps

Prior to adopting DevOps, Pearson was bogged down by manual processes, especially in application security. “People sent requests buried in email or, if you were lucky, in a Google spreadsheet. There were very few clear lines and hand-offs between the different activities that were the responsibility of the AppSec group,” explains Tesauro. It was a very manual, custom approach in terms of request handling: someone would respond to a request with an activity, which would require a report that was then emailed.

At the time, Pearson had no single, well-established methodology or workflow for these activities. There was no particular look and feel or design for creating dynamic, manual or static assessments. There was no list of inputs into the process or outputs to expect at the end of the process. “At best, everything flowed in an ad hoc fashion,” says Tesauro.

Then, about two years ago, Tesauro and a senior-level peer at Pearson attempted to prioritize those apps the company most needed to assess for security and related issues. They had hoped and planned it would be about 10 apps, to keep the number and the workload manageable. For political reasons, they were able to settle on no fewer than 64 apps that needed appraisal. “We ended up being able to assess only 44 out of the 64 top apps. There are 2,000 and some-odd apps at Pearson, in rough numbers. Just the scale told us we were going to fail in the long run,” says Tesauro.

Ramping Up to Change

To resolve this app assessment challenge, Tesauro looked to institute DevOps and Build Pipeline approaches to lay the groundwork for eventually integrating security into the various development teams at Pearson. “I made equivalents of DevOps and Build Pipeline approaches for how we did work in the AppSec program at Pearson,” says Tesauro. These included standard methods of input and intake of service requests similar to how the business produces software development targets for a DevOps shop to hit. That’s when Pearson began to work on instituting and leveraging ThreadFix.

“ThreadFix was one of the first two parts of that pipeline,” he says. The other part of the AppSec pipeline solution was what Tesauro calls the “Bag of Holding,” a mechanism and repository for tracking all the team-to-team interactions and work assignments. That feeds into ThreadFix.

During that time, and for about the first half of 2015, Tesauro and a teammate automated a number of manual steps by creating code to perform the “mindless work” so developers could concentrate on their core business instead. “Now when the static code analysis tool Checkmarx finishes its analysis, it generates a report, washes the directory and pushes the report into ThreadFix,” says Tesauro. He also automated a number of other test applications and tools.

Stay tuned for part two of this case study, coming soon.

February 12, 2016
Minimum Viable App Doesn’t Mean Minimum Security

It’s estimated that the total market for mobile apps will hit $143 billion this year. A big portion of that budget will be enterprise mobile app development. By next year 25 percent of enterprise IT budgets will be aimed at their mobile app efforts. Yet, despite these efforts, most enterprises are still falling behind in their mobile app development pipelines by 12, 15 and even 20 weeks.

To help clear that backlog and meet their internal mobile app demand, more enterprises are focusing on delivering the mobile apps with the features that hold promise to produce the most return on their efforts; that is, the apps that people likely will use and will do the most, for the least investment, to help to improve their daily work lives and productivity. Or, this minimum viable product (MVP) is the minimum required in an app to prove out its app concept.

But when moving apps out quickly, enterprises risk skimping in areas of quality and especially security, which can pose a risk to data that should be handled with care, notes Isaac Potoczny-Jones, research lead, Computer Security with security research and development firm Galois.

“There’s definitely a lot more development in mobile happening,” says Potoczny-Jones. “I think the [security] best practices in mobile aren’t as well-developed as best practices for the web. I think that’s getting a little bit better, and there’s a very fascinating challenge with security [with MVP] because security is a non-functional requirement.”

Of course, apps must be developed with good mobile security—including app password management, server side controls, cryptography and other best practices—in mind. The OWASP Top 10 Mobile Security Risks provides an excellent overview of common mobile risks and associated mitigations.

One of the challenges with mobile security testing is that the best practices and associated processes are not well understood by most, at least not yet, and quality mobile security testing tools are not deployed in many organizations. Plus, those organizations using some of the common mobile security testing tools find that they don’t always suffice and they often have to build their own automated toolsets.

The risk with fast-tracked MVP apps is that they never get anywhere near a security test before being shipped to production. But these apps—just like any other apps that get near enterprise data and networks or may access sensitive, confidential or regulated data—must be vetted, threat modeled and tested (static and dynamic app testing), along with the usual quality tests. And with MVPs, it’s just as important that this testing be an integrated part of the process from the beginning.

The best way to achieve this, of course, is through awareness and secure code training with developers.

Companies may want to consider creating an MVP development guide that could detail security considerations for the MVP. Such a guide could help developers determine what security best practices to follow, as well as what apps need to be sent to the security team for reviews—and when.

Potoczny-Jones says there’s no reason, except for maybe carelessness, why MVP apps are being built with minimum security considerations, as most lean development methodologies have security testing built into their processes. “Once you get these teams to include security testing being a part of [what they consider] ‘being done,’ which I don’t think a lot of people have, then they’re going to do the right things. You’re either going to start to build security either into the user stories or the acceptance testing,” he says.

That’s for sure, and it shouldn’t be left to the end of the development process. “You can’t leave it to just be at the end of the process. If you leave security testing toward the end, naturally your schedule is going to slip. You’ll find that there’s a lot more work to do. Then you’ll be in this unfortunate position of having to decide whether to fix things and let the schedule slip, or choose to let something go out the door that’s not secure,” Potoczny-Jones says.

February 10, 2016
How DevOps Helps Improve Application Security

The DevOps trend is gathering pace, evolving from a niche to a mainstream strategy. Organizations are overcoming the barriers to successful implementation and finding real benefits in terms of speed and efficiency. But there are lingering issues to solve with regard to security. As companies look to push more changes to production more quickly, risks increase from multiple areas including integrating third-party software with known vulnerabilities, creating security defects in the code, not being able to fix the security issues that do arise and poor configuration.

According to the 2015 Cost of Data Breach Study from IBM and the Ponemon Institute, the average total cost of a data breach for participating companies increased 23 percent in the last two years to reach $3.79 million per breach. As DevOps presses ahead, security isn’t being considered often or early enough. Maybe a more “rugged” DevOps approach is needed.

Building in vulnerabilities

The vast majority of data breaches last year were entirely preventable. According to Verizon’s 2015 Data Breach Investigations Report, 99.9 percent of the exploited vulnerabilities were compromised more than a year after the Common Vulnerabilities and Exposures database, which lists known information security vulnerabilities and exposures, was published.

Developers frequently integrate open source code with third-party applications that have known vulnerabilities, providing would-be attackers with a way in. It’s difficult, time-consuming and expensive to close these loopholes after the fact.

Expand the DevOps mindset

We see many benefits when development and operations teams work closely together, so perhaps it’s time we applied the same logic to security and risk experts. Putting them into the DevOps mix earlier in the process could lead to an increase in empathy and understanding—and an injection of expertise at the outset that could save a lot of pain later in development.

Security and risk professionals can work directly with developers and operations to identify and remediate potential vulnerabilities. They can paint a picture of how to decrease the attack surface, set up alerts and boost response times.

Integrate automated security into your pipeline

If you can embed security goals into your continuous delivery processes, it should be possible to automate a lot of your security checks. Stick to the same principles as your wider development by making frequent, small, fast improvements to security. Automation can free up your security experts enough to find underlying weaknesses and tackle them.

The average organization receives almost 17,000 malware alerts in a typical week, but only 19 percent of those are deemed reliable, according to the Ponemon Institute, in this Malware Containment Report. This means two-thirds of security staff time is wasted because of faulty intelligence, at an average annual cost of $1.27 million. Only 41 percent of organizations have automated tools to capture intelligence and assess threats, but those that do report that 60 percent of malware containment can be handled without any human intervention.

It’s important that security professionals work directly with your developers and operations people to integrate vulnerability tests and security scans into your continuous delivery pipeline. They’re engaged in an ongoing battle with hackers, so make sure to continually review and tweak the tests that are run.

It also helps to have versioned definitions of all your systems, so you can readily and automatically scan for vulnerable systems when new vulnerabilities are announced.

Don’t forget to measure

Testing the effectiveness of your security measures is vital. Run penetration tests and employ destructive testing tools to see how well your processes stand up. Make sure you have clear remediation plans and that you can deploy quickly to roll back or forward to eliminate any vulnerabilities.

Security is too important to be an afterthought. We know there are lots of benefits to breaking down silos—let’s extend that beyond development and operations to include security. Build it into your continuous delivery pipeline and automate where possible, and you’ll get greater value from your security experts. You’ll also turn out better-quality software.

About the Author
Andrew Phillips is vice president, DevOps Strategy for XebiaLabs, a provider of automation software for DevOps and Continuous Delivery. He sits on the management team and drives product direction, positioning and planning.

January 11, 2016
Why do you need to implement a DevOpsSec team?

Just 20 years ago, organizations relied on a single wall of defense to secure their applications and networks. Fast forward to 2015 and that large fence is no longer adequate. With the proliferation of mobile, cloud and SaaS technology adding to the complexity of ever-advancing systems and networks, it becomes much more important that teams across an organization work together as one, toward a common goal. We’ve already seen enterprises adopting new methods of organizing internal structures to increase collaboration through DevOps, but as security continues to be top of mind for organizations, many are looking to further this approach by including the security team in the DevOps conversation. With a DevOpsSec team, organizations can work toward delivering software that is not just reliable, but also secure.

Introducing security to DevOps provides the means to this protection by reducing the number of bugs and vulnerabilities during the build process before code hits production systems. Moving security as close as possible to the code and data will bring a large number of high value benefits to an organization.

The first benefit of introducing security to DevOps is the enablement of team collaboration through tight feedback loops. Development, operations and security teams all have different goals and are motivated by different things, which are often contrary to the other teams. To ensure that these groups don’t work as adversaries within an organization, DevOpsSec encourages them to work together, pulling from all parties’ strengths and building a collaborative and engaging environment. This collaboration offers transparency into the assorted issues that arise within each team, establishing a deeper level of understanding and respect across the board.

The second benefit is that DevOpsSec provides a wider perspective across previously siloed teams. As a result of greater team collaboration, Dev, Ops and Sec teams are able to gain more insight into how the other teams operate. This widened perspective decreases friction between them, further revealing common goals and generating more natural solutions. Overall, the assortment of perspectives results in more efficient strategies for the organization in keeping its systems secure.

Lastly, the implementation of DevOpsSec ensures faster response time to issues. As applications and systems become more distributed and complex, it becomes more difficult to identify and fix bugs and vulnerabilities. Developers are writing and pushing code faster than ever before, and what used to be monthly or longer release cycles can now be measured in hours. This is due in part to the fact that code is being used both inside and outside our networks, requiring more thorough network security. The new normal will be found in developing DevOpsSec teams and moving the security as close as possible to the code and data. Through more continuous review processes and more ownership over code in production, the merging of DevOpsSec can mean faster times in closing feedback loops and will ultimately help organizations to operate more efficiently.

So what will an organization look like after implementing DevOpsSec? As a result of the cross pollination between teams, organizations will have curated an elevated platform for innovative ideas, gained greater insights across teams and developed faster response times to help the business run smoother. With DevOpsSec in affect, organizations will better understand and anticipate security issues and the decisions required to diminish them.

December 17, 2015
Getting Rugged DevOps Right
Two Perspectives

Jack, an accomplished application security pro, tells me, “The developers won’t talk to us. It’s like we speak a different language. They are releasing new builds so fast, how could they check each one for security vulnerabilities? We can’t move as fast as they do.”

Then in the next moment, Diane, a DevOps pro, let’s me know, “Our current security team’s tools and practices can’t keep up with the pace we have now established. If it doesn’t fit, it doesn’t get done here.”

I have heard this little ditty ‘bout Jack & Diane so often in the past two years, it could be a hit record. I imagine you have heard it too.

The Slow Lane Won’t Lead to Rugged DevOps

Let’s visit Jack’s world, first.

When visiting a well-known bank last month, they shared insight on their current application security practice. They have 10 full-time people employed (offshore where personnel costs are lower) to analyze a set of 100 applications. The bank has over 2000 applications, but the security practice can’t scale to access their entire portfolio. In 2.5 years, they had only been able to cover 5% of the application portfolio.

The application security team employs an application security tool originally built for waterfall-centric development timelines. As much as they want it and need it to move faster, it is not really for “continuous” velocity.

Each scan of an application can require anywhere from four hours to two days to get an assessment report. The reports average about 30,000 potential defects which then require further analysis. That analysis may take up to two weeks in order to sift through thousands of false-positives and false-negatives. While this security practice is critical to the bank, it cannot keep pace with development practices that are aiming to go much faster in order for the bank to remain competitive in their industry.

The Continuous Gap

Sound familiar? It should. This scenario is playing out all across the DevOps and Continuous Delivery landscape. It is reflective of what I call “The Continuous Gap”.

Leaders in Rugged DevOps practices aim to minimize the “Continuous Gap”.

In Diane’s world, DevOps teams pursue “shift left” strategies in an effort to build quality in from the beginning. Shifting left enables them to bake in the right code, components, configurations, and practices from the beginning. When done right, velocity increases dramatically, while operating costs are minimized, and unplanned/unscheduled work is reduced. Investments can then shift more in favor of innovation over upkeep and maintenance.

The Old-School Rub

Jack’s world of traditional application security practices often wait to check for security vulnerabilities at testing or release stages of the SDLC. There are two reasons for this: (1) some security tests like static or dynamic analysis can take hours or days to perform and (2) security teams cannot embed themselves earlier in the SDLC (due to political, organizational, or operational obstacles) without dramatically slowing development in a high velocity world.

If you are using old-school application security tools, you will continue to be blocked from getting more deeply entrenched in development. New velocity requirements call for new approaches.

The New-School Shifts Left

A number of newer application security solutions and practices been introduced recently that are development and developer-centric. For example, imagine if build managers could analyze every open source component used in every build for known security vulnerabilities.

What if, developers could access information inside their IDE that would inform them if a component they were planning to use in an application was known to be vulnerable? What if developers had access to spell-check like alerts of security issues as they were creating their code?

Furthermore, imagine if information was available that not only told the developer of a known security defect, but directed them to an alternative safer version of that component to use. Components would be automatically vetted against corporate security policies at the instant they were chosen by a developer. When 90% of an application is composed of open source and third party components today, automatic analysis early in the lifecycle save millions of dollars. This how Rugged DevOps rolls. This is Diane’s world.

The evolution of Rugged DevOps is forcing application security practices to shift left.

But Diane’s world (and your’s for that matter) are not just about increasing velocity. All organizations need to consider operational costs to both detect and remediate security vulnerabilities in their applications. We all realize that the further along we are in the application development lifecycle the more costly fixes become. Feel free to apply your own cost figures to the chart below, but you should also note that these calculations do not include breach cost, help desk calls, maintenance, time-to-market, reputation or stock price.

Cost considerations for Rugged DevOps practices compared to waterfall approaches.

Rugged DevOps: Shifting Gears…Quickly

Shifting from old-school to new school approaches doesn’t take long. On a recent visit to one of the largest insurance companies in North America, they shared their tale of transition. Of five major applications that run their business, one in particular had 40,000 different files that needed to be analyzed. Their old-school approach involved a lot of manual code investigation and required about two-and-a-half weeks to complete the analysis of that large application. The new approach that used automated analysis of security vulnerabilities took two minutes — and produced identical results.

A government tax office wanting to shift security analysis of applications from hours (outside of development – Jack’s world) to seconds (inside of development – Diane’s world) was able to complete the first pass analysis of their existing portfolio of 600 applications within two working days. The security team was not only faster at identifying known security vulnerabilities in applications, but could also quickly identify alternative open source and third-party software components that were safer to use. The security team was not simply discovering issues, but the new class of Rugged DevOps solutions were aiding in guided remediation.

Questions to Ask About That Rugged DevOps Solution

There are several companies and open source projects that now offer application security solutions that work at extremely high velocity. When exploring solutions to match the velocity of your Rugged DevOps practices, consider asking the following questions:
1. How long does it take to complete the analysis of a small, medium, and large application?
2. Do developers use these tools, or are they only meant for security personnel? Do you have members of development teams that act as positive references for your tool?
3. Does the analysis require further investigation of the findings, or does it pinpoint the root cause of the issue?
4. Does the solution only identify vulnerabilities or does it help guide remediation of issues?
5. What is the balance of false positives to positive alerts generated by the solution?
6. How many people are employed to support the solution in environments similar to ours?
December 10, 2015