Cloud Security Alliance and SAFECode Develop Training for Improved Software Security Using Cloud and DevOps Practices
Software assurance is one of the most important and possibly one of the least understood areas of software development today. Software assurance is a comprehensive process that encompasses a set of design, coding and testing methods for ensuring that software functions as intended without introducing vulnerabilities, malicious code or defects that can bring harm to the end user. This approach is especially important in the cloud because increasingly the tools for developing applications are coming from cloud providers. The architecture for applications is changing rapidly and requires developers to understand the risks and vulnerabilities when developing applications in the cloud environment.
As we continue to see vulnerabilities within applications that lead to exploitation and theft of data, there exists a lack of acknowledgement in how to properly define and address these issues. With increased expectations on reducing time to market, development teams are pressured to work in sprint cycles using agile methodology thinking. New feature development is put first and developing secure code can become an afterthought.
While individual companies do implement effective methods for developing and delivering more secure and reliable software, except for a small number of organizations such as Software Assurance Forum for Excellence in Code (SAFECode) and the Cloud Security Alliance (CSA), there have been limited coordinated, industry-led efforts to build upon this positive work and promote best practices to advance software assurance more broadly, especially in cloud technology.
Inaugural Developer Day Planned for Sept. 12
The inaugural Developer Day event launched by the Cloud Security Alliance and SAFECode is a workshop developed to address these issues by educating software professionals on the challenges of improving software security using cloud and DevOps practices. A unique curriculum was developed by CSA and SAFECode to address the challenge of improved security using cloud and DevOps practices. The event is free but pre-registration is encouraged:
WHAT: SAFECode/CSA Developer Day
WHEN: Monday, Sept. 12; 1-6 p.m. PDT
WHERE: Adobe Systems Incorporated Corporate Headquarters
345 Park Avenue, San Jose, California
Park Room, East Tower
Developers play a critical role in secure software assurance, and in today’s IT landscape, this role has never been more important. The application of effective software assurance methods is a proven way of enhancing and preserving trust and reliability of software.
A Practical Primer on Software Assurance
The half-day Developer Day event provides software developers with an important general primer on the core principles and applications of software assurance, and how to build in security utilizing cloud and DevOps practices. Attendees also will be provided with insight on state-of-the-art software assurance trends and learn how they can deepen their knowledge of software assurance. The event agenda includes three sessions:
SAFECode: Driving Software Assurance among Software Professionals
Fundamental Practices for Software Assurance
CSA: Cloud + Dev = Security Awesome
Putting Theory into Practice: Software Assurance Case Studies
SAFECode and CSA created the Developer Day with two goals in mind. The first was to share recent developments and trends in the practice of software assurance across a number of different domains. The second was to demonstrate the top ways to combine development practices such as DevOps with cloud deployments to increase security without slowing things down.
Online Software Assurance Training Available
If you can’t make Developer Day, SAFECode and CSA also recently launched a jointly developed free, online, on-demand cloud security training program called, “Basic Practices for Service Development of Cloud Applications.” The two-part training program teaches students about different cloud models as well as basic practices and aspects of secure development of cloud applications. It is part of a broader security engineering curriculum made available for free by SAFECode.
About the Author / John Yeoh
John Yeoh is the Senior Research Analyst for the Cloud Security Alliance (CSA) working within industry working groups, SDOs and strategic relationships in the development of cloud security standards, tools and solutions and strategy development. With over 15 years in research, John has authored reports on IT, cybersecurity, cloud and new technologies. His thought leadership has been presented in SC Magazine, USA today, Information Week and others, and he currently sits on numerous technology committees in government and industry. John’s graduate studies include Massachusetts Institute of Technology and University of Southern California with undergraduate work at Eastern Washington University and University of Washington. Connect with him on Twitter and LinkedIn.
By now, surely everyone has seen cooking competition shows such as “Hell’s Kitchen” and “Top Chef,” in which people compete to create and serve the best dishes as quickly as possible. These hit TV programs are like the DevOps world, which also consists of people creating and releasing the best software as fast as they can with whatever they are given. In both instances, the best use of random ingredients brings rewards and failure brings disappointment.
DevOps is becoming evermore common as companies in all industries work to unify their developers and other IT staff while automating as much of the process as possible, creating nimble, fast-moving teams. Think of it in the same way professional kitchens have cooks dedicated to specific stations, such as vegetables or fish, and are able to react swiftly to whatever orders are placed. By redesigning their in-house teams in this fashion, organizations can add speed, agility and resilience to critical functions.
But, often what’s forgotten in the high-pressure, rush-rush-rush world is the critical importance of security and regulations. Governance, risk management and compliance (GRC) always must form the base decisions; otherwise; the final products will either not be able to be used or, worse, be dangerous to the company, its customers and its shareholders. It’s really no different than cooks having to abide by health code regulations or risk sickening and possibly even killing their diners. Don’t think GRC is that serious? It wasn’t long ago that Dwolla was fined $100,000 by the Consumer Fraud Protection Bureau (CFPB) for lying to customers about data risks. That was the CFPB’s first fine and you can bet more are sure to follow.
Of course, a key difference is that in the business world, regulations and compliance standards constantly are being created or changed. That makes DevOps even more challenging, but that challenge cannot mean ignoring GRC. In fact, GRC should be seen as a key DevOps enabler, not an obstacle. An organization’s legal and compliance team can take advantage of highly agile, forward-moving DevOps teams to design and implement changes that satisfy risk and control points (resulting in successful audits and avoiding fines) while, at the same time, staying abreast or even beating the competition.
The key here is to ground DevOps in GRC requirements so they become second nature and security measures are incorporated effectively into all DevOps processes, even automated ones. It’s crucial these measures are seen as integral to the processes and not simply layered on top as an afterthought, just as you wouldn’t try to get raw chicken juice off of lettuce after you’ve made a salad.
Tactically speaking, how is this accomplished? DevOps teams need awareness and training. They need to learn the rules and laws specifically governing their particular industry, and how to implement them. And, companies need to have internal audits and other review policies in place to ensure GRC is enforced.
For all of this to happen, however, a very important role must orchestrate it: management. Just as every kitchen depends upon a head chef to ensure not only that each station is obeying health codes (i.e. the law) but also that overall the meal is being prepared and delivered properly, company management must assume its authoritative role in setting up and defining the organization’s internal communication. This means breaking down silos and coordinating a regular flow of information from Compliance to DevOps team and back again.
If this is done properly, DevOps can enable an innovational Nirvana, with companies boosting speed while maintaining security, creating the perfect consumer experience.
About the Author / Robert Hawk
Robert Hawk serves as Information Security Expert at xMatters, Inc. He has extensive experience in information systems security, computer security, cyber security, information assurance and governance, risk, and compliance (GRC) management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on LinkedIn.
I went seeking honesty at a DevOps conference and met Diogenes.
Diogenes of Sinope was a controversial figure in ancient Athens who was known for walking around the famed ancient city—some say in the nude— during daytime with a lamp in his hand. He parried inquisitors who questioned his strange habit of using a lamp by day by insisting that he was looking for an honest man. At the recent DevOpsDays Boston, I actually met Diogenes. True story. See picture below. (Thankfully, he was wearing clothes.) But, as you probably guessed, this was not the man with the lamp, but rather one of the many conference organizers looking to help less-acquainted individuals find their way around the many meetings and speakers that filled the two-day conclave. Indeed, my Diogenes was instrumental in organizing the conversations and lectures that proved both honest and helpful. Rather than a self-congratulatory summit, the two-day meeting was an honest conversation highlighting the advantages as well as many of the stresses befalling organizations that have adopted DevOps.
I found the most honest discussions were a floor up and a bit removed from the topics discussed in the main ballroom. These discussions were given the informal title of “Open Spaces” and were run in a typical un-conference format. These conversations were the real opportunities to learn about the stresses of implementing the modern portmanteau of DevOps.
Tensions Between Dev and Ops: Why Can’t We All Get Along?
One of the most interesting discussions in the Open Spaces looked at the dynamics between Devs and Ops. Like with any two groups that need to work together to accomplish larger organizational goals (think Sales and Marketing or Design and Engineering), there are inherent tensions that need to be overcome. The tensions between Dev and Ops are based on the different mission each pursues. Dev is striving to get software out the door as quickly as possible and push software updates forward. Ops is guided by the need to keep the ship as steady as possible, which often means limiting updates, as every update opens the door to potential bugs and deployment challenges. Starting with this premise of conflicting motivations, issues of trust and respect further complicate the relationship as each sees the other as trying to control the process.
Yet, participants in this Open Spaces discussion were hopeful that tensions could be dissolved if management played an active role in creating cross-functional teams and managing workloads better. It was suggested that by essentially seeding Ops with Devs and vice versa, a greater community of understanding could be created. By promoting this cross-pollination, there would be greater understanding on both sides the implications (from the Dev side) of pushing software over the wall to Ops too quickly. From the Ops side, there would be greater understanding that 100 percent uptime is incompatible with dynamic product cycles that encourage innovation. A common and acceptable level of uptime needs to be agreed upon by both sides.
For example, creating demos and code walk-throughs so both Dev and Ops can comment on potential problems and issues allows both Dev and Ops to see issues at the beginning rather than at the time of deployment.
Blameless Post-Mortems in DevOps: Can They Exist?
Another fascinating discussion in the Open Spaces focused on blameless post-mortems. Postmortems first and foremost suffer from an image problem. I believe it starts with the root word “mort” and it doesn’t get much better. To be clear, there was a lot of back and forth during this Open Space about the difference between a “postmortem” and a “retrospective.” Retrospectives are usually a weekly or bi-weekly event that bring to light the multiple root causes that are leading to defects or causing success through a review of RCA. In typical DevOps, one-week sprints are followed by a retrospective. Usually, the more data you can bring to a retrospective, the better. Post-mortems, on the other hand, result from an incendiary incident that was unexpected and undesired.
Since post-mortems inevitably occur due to human oversight or lack of planning, there is no amount of thinking or planning that can prevent a crisis and thus prevent a post-mortem. As such, effective management will make post-mortems as painless as possible. The goal is to have blameless post-mortems balanced with accountability. According to one participant,
“No one wants central casting to send in a screaming manager in a time of crisis who is only interested in assigning blame. That doesn’t help anything.”
Importantly, you cannot fire yourself out of a post-mortem. Post-mortems are a necessary instrument to get at the root causes of issues. And while several different events can cause one issue, the post-mortem will at least begin to look at the process which caused the chaos. By not making the goal of post-mortems to find a scapegoat, the participants in one of these sessions can actually work on effective problem-solving.
The goal of post-mortems needs to be effective problem-solving with the intent of committing the lessons learned to an actual document. It is not enough to let the lessons learned remain as an informal corpus that lives only in the heads of the engineers involved. Instead, documentation is required and it has to be in accessible place. Furthermore, it needs to be summarized and presented to management in either a lunch-and-learn or seminar so that the lessons learned then become actionable.
Furthermore—and this was perhaps the most interesting part of the discussion on post-mortems—effective post-mortems are about getting Dev and Ops out of silos. There is no automation tool that will make Dev and Ops work together. Dev and Ops cannot just be about finding another automation tool. Instead, management needs to step in to help the process. Management needs to take engineers out of their silos and get them to work together if post-mortems are going to be really effective.
Are You Feeling the Burnout Yet?
After so many hours of interesting discussion in the DevOpsDays Open Spaces, I too was beginning to tire a bit. So perhaps it was well-planned to move on to a discussion on avoiding burnout.
The artifacts of burnout are seen throughout the DevOps world as engineers constantly change jobs. This might be the phenomena of the “shiny orb,” where engineers always feel that there is a better, higher-paying job on the other side of the fence. However, as much as that might be true, it is equally the case that engineers are trying to escape burnout.
According to the kanban methodology, which is woven into DevOps, you only pick up work as you can process it. Yet, DevOps practitioners often pick up work because they want to feel like they are team players or invincible or because they underestimate the work’s demands. They also fear the “imposter syndrome,” whereby colleagues seem less genuine if they don’t accept a piece of work offered to them. Inevitably, because the work is more than the engineer can handle, he or she becomes overwhelmed and is too proud to reach out for help.
In a well-managed workplace, admitting overwork would not be an admission of failure. Instead, there would be a supportive culture to help the engineer or better mentoring on how to get through a challenging issue. “One-on-ones,” where the manager and individual contributor sit down together, would effectively solve the issue.
But given the idiosyncrasies of workplaces, good management is not a given and engineers are often left to find their own coping techniques to help avoid burnout. The participants in this particular Open Space came up with the following gems:
Brain dumping. Empty your brain by putting all the thoughts and tasks that remain on your list and in your brain at the end of the day onto post-it notes. This helps avoid burnout because you are able to clear your brain prior to leaving work.
Create a Slack-based or bullet journal as a way to write yourself notes and create a list of priorities.
Follow the Pomodoro technique. Take a five-minute break every 25 minutes and a 15-minute break every two hours to better monitor how much time you are devoting to an issue and also to ensure you don’t forget to get a bit of movement into your day.
Learn how to say ‘no’ to requests. It’s a very simple word, but uttering ‘no’ once in a while will ensure that you mark boundaries and don’t take on more responsibility than you can handle.
Enlist management to make them aware of time you are spending beyond the normal working day and try to figure out ways to better manage the schedule and avoid burnout.
The participants of this Open Space left with some new techniques to consider in avoiding engineer burnout. Hopefully, they will be implemented to practical advantage.
Conclusion
My first DevOpsDays conference was a true eye-opener. I was lucky to get my education among such thoughtful and well-spoken individuals. I look forward to future opportunities to learn at the foot of Diogenes.
About the Author / Orlee Berlove
Orlee Berlove is the Marketing director at OnPage Corporation located in Waltham, Massachusetts. OnPage is a cloud base incident alert and management system that elevates notifications so they continue to “ALERT-UNTIL-READ” so it’s not confused with email, SMS or phone calls. Incidents can be programmed to arrive to the person On-Call and can be escalated if they are not attended to promptly. Follow OnPage on Twitter and LinkedIn.
To enable faster and better response to changing customer needs, enterprises are increasing their release frequency for applications. This, in turn, demands tighter alignment and collaboration than traditionally has been seen between the line of business, development and IT operations, driving the need for enhanced collaboration, automation and information transparency among these groups. To achieve seamless internal collaboration, many enterprise customers are adopting a DevOps approach.
DevOps is an enterprise capability that enables the continuous delivery and continuous deployment of software. It reduces the time needed to address customer feedback. DevOps brings once-siloed Dev and Ops together to improve agility and achieve these benefits:
Improves collaboration between developers and operations specialists by using shared DevOps tools.
Facilitates continuous delivery of software by enabling collaborative testing throughout the development and release processes.
Automates the manual processes of release management, infrastructure provisioning, orchestration, monitoring, containerization and virtualization.
Corrects misalignments of people and goals by building closer links between developers and operations.
Incorporates customer feedback in the development process to facilitate agile development.
IBM has identified six phases in the DevOps life cycle, plus necessary cultural considerations, for successful implementation of a DevOps approach (Fig 1).
Fig. 1 – Six phases of the DevOps life cycle
In the Manage phase of the DevOps life cycle, continuous monitoring of applications in production environments is typically implemented with application performance management (APM) solutions that intelligently monitor, analyze and manage cloud, on-premise and hybrid applications and IT infrastructure. These APM solutions enable you to monitor your users’ experience and improve the stability of your application infrastructure. It helps identify the root cause of issues quickly to proactively prevent outages and keep users satisfied.
With a DevOps approach, we are also seeing more customers broaden the scope of continuous monitoring into the staging, testing and even development environments. This is possible because development and test teams that are following a DevOps approach are striving to use production-like environments for testing as much as possible. By running APM solutions earlier in the life cycle, development teams get feedback in advance of how applications will eventually perform in production and can take corrective action much earlier. In addition, operations teams that now are advising the development teams get advance knowledge and experience to better prepare and tune the production environment, resulting in far more stable releases into production.
Applications are more business critical than ever. They must be always up, always fast and always improving. Embracing a DevOps approach will allow you to reduce your cycle times to hours instead of months, but you have to keep ensuring a great user experience! Continuous monitoring of your entire DevOps life cycle will ensure development and operations teams collaborate to optimize the user experience every step of the way, leaving more time for your next big innovation.
This continuous monitoring blog is the first in a series that focuses on collaboration between development and operations teams. We will explore this topic in detail in upcoming blogs:
Synthetic Monitoring: Developers, testers and operations staff all need to ensure that their internet and intranet mobile applications and web applications are tested and operate successfully from different points of presence around the world.
Alert Management: Developers, testers and operations staff all need to send notifications via email, voice mail, text, mobile push notifications and Slack messages when specific situations or events occur in development, testing or production environments, to get the right people’s attention and to manage their response.
Deployment Automation: Developers, testers and operations staff use different tools to schedule and deploy complex applications and configure them in development, testing and production environments. We will discuss the best practices for these teams to collaborate effectively and efficiently and avoid potential duplication and erroneous information.
Analytics: Developers need to be able to look for patterns in log messages to identify if there is a problem in the code. Operations need to do root cause analysis across multiple log files to identify the source of the problem in complex application and systems.
Stay tuned for the next blog on synthetic monitoring in the series and register for an upcoming interactive webcast, “Learn Why We Must Shift APM Left in the DevOps Lifecycle.”
About the Author / Arun Biligiri
Arun Biligiri is the leader of the Application Performance Management Offering Management team at IBM. Arun has over 20 years of experience in technology in various different roles including entrepreneurial, development, product management and sales engineering. He has worked closely with innovative enterprises and has extensive experience in addressing cloud, analytics needs in efficiently managing their data centers and clouds. He has an MBA from the Wharton School, and MS from the University of California, Berkeley. Connect with Arun on Twitter / LinkedIn
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.
DEF CON is one of the most controversial conferences in the world. Only at that annual event have arrests been made, legal threats shut down presentations and zero-day attacks been anted in Texas Hold ’em games.
The Usual Suspects
This is a conference of people who grew up like me—people who, at 11 years old, were using IRC (internet chat relay) to share API (application programming interface) documents or download random material such as, “The Anarchist Cookbook.” We were influenced by movies such as, “The Matrix,” and “Hackers,” all the while thinking elite hacks were the cool thing to do. We spent lots of time playing Quake and other games. As we grew up, we may have gotten into trouble building projects using proggies or sharing things we weren’t supposed to share. Most of us grew up using computers to build software and make money. Some of us graduated from college and found great jobs for our skills.
You start with chat rooms on AOL and dive deeper into IRC. You may meet people playing peer-to-peer games such as Quake. Those people share information, and, before you know it, you’ve downloaded software over peer networks and you’re sharing cracks. This is your hidden world, and your friends are handles with no name, age or location.
Then one day you decide you’re going to meet all these handles in person at a central location that is easy to get to. You’re going to save up some really good cracks you haven’t shared yet for when you meet them. That, to me, was the adolescent rebellious start to DEF CON.
Now, as adults, we appreciate the novelty of slipping away into childhood by attending DEF CON to witness new hacks and meet childhood hacker friends. It’s like meeting a bunch of people at your house who haven’t seen each other in a long time or only knew each other through internet chat rooms. It’s a good time to connect; it’s great to feel that energy.
Going Down the Rabbit Hole
Hackers are just curious folks who are so bored with all the content they consume that they turn the internet into a playground. Like every playground, there are good guys and bad guys. Sometimes they’re forced to get along. Sometimes they fight. Sometimes they decide to attack a system just because the company that runs it laid off a loved one. Other times they are just playing a friendly game of King of the Hill. You can take it too far and get in trouble or get a wake-up call. Or, you may simply grow out of it. No matter the situation, the curiosity and love for the internet remains with you; that is why DEF CON is attractive.
DEF CON is white hats teaching black hats and black hats teaching white hats with a lot of gray in between. Everyone gets along and smiles as they watch “The Matrix” or “Hacker Jeopardy” together.
Distinguishing the Hackers from the Hacks
I was waiting in line. I always communicate with the people in line and ask them about the conference, current presentations and whether they have had any experience setting up XYZ or running up a large sheet of attacks using cloud networks. At this year’s event, most of the people I ran into looked like “hackers” but had no clue what I was talking about; they just uncomfortably laughed. It’s funny: They were going to presentations to see somebody talk about something highly technical, yet, they didn’t have a clue.
Lots of folks had badges, hung out and looked as though they were on vacation and decided to check out the conference. This group, I believe, came because the conference was located in a casino in Las Vegas. The whole Vegas thing is probably the top reason why DEF CON attracted larger crowds.
I noticed I found more competent folk at the Villages—different sections focusing on topics such as packet hacking, car hacking and social engineering. Villages had more unique, specific details on the concept of hacking in certain arenas. I found people were more in-tune and focused here. The Villages were away from the four main presentations rooms, which meant fewer tourist types. The Villages were where you found the passionate hackers.
White or black, it was a lot of gray. I didn’t see my friends who specialize in network protection for a living using hacker tools maliciously; rather, they were curious to know how the tools work. After Justin got his MitM (man-in-the-middle) attack working, he smiled and looked at me, “Is it this easy!?” Then, “How do we stop this? Is it really just making everything TLS? That can’t be the only way.” So we ran a few Google searches to poke around deeper. When moving around the conference, you saw guys sitting on the ground running these attacks; they were just phishing to add to the wall of sheep.
Was the guy who got paid to snoop at the Democratic National Convention convention with MitM attacks there? He might or might not have been. He might have been pioneering these attacks and learning from presenters, or he might have been so beyond what is shared at DEF CON that it was a mere novelty to attend. Even with DEF CON making it really easy to go undetected by using cash transactions, it’s still 2016 and surveillance cameras were everywhere—especially in casinos. If you’re looking to keep a low profile, DEF CON is the last place you’d want to be.
So, I’m going to go out on a limb and say that the white hats and some grays were present with maybe a Sith Lord lurking in disguise. The true black hats were most likely reporting in remotely to their Sith while they observed petty hacks and recruited from a safe distance. Or maybe, just maybe, they were in board shorts acting like a clueless tourist.
About the Author / Randy Apuzzo
Randy Apuzzo is founder and CEO of Zesty.io, the SaaS CMS Company. At age 12, Randy was hacking corporate sites and crashing systems for fun. As an adult, he applies his computer science and branding background as an industry visionary, architecting scalable solutions that help companies accelerate and scale their global digital content strategies. He is revered for empowering businesses with technology that grants agility, cost savings, security and increased market share. To connect with Randy, please visit https://www.zesty.io, Facebook/GoZesty, LinkedIn/Zesty-io, @RandyApuzzo and @Zestyio.
To remain competitive in today’s software-driven economy, organizations of all sizes are investing in DevOps to become better at releasing software. Although the ROI is evident in the IT and business performance of organizations that have successfully implemented DevOps practices, the journey still can be challenging.
There are troves of resources available to help companies begin or continuously improve along their DevOps journey. However, oftentimes it’s the practitioners—experts from the community who live and breathe DevOps every single day—who can offer the most insightful tips.
To that end, Electric Cloud hosts a community video podcast series titled, “Continuous Discussions” (#c9d9, for short). Each episode focuses on a different topic and brings together a group of expert panelists to discuss all things DevOps, Agile and continuous delivery (CD).
Why? Because we all understand DevOps is a team sport. It’s all about collaboration: bringing people together and continuously improving through shared learning and experimentation. Community is at the core of any DevOps initiative, and connecting with peers and sharing experiences is the best way to accelerate our mutual success—so we can all get better at delivering software, together.
These casual #c9d9 chats are often funny, entertaining, thought-provoking and—always—educational! These are a great way for the IT community to pinpoint emerging patterns, discuss challenges and highlight tips and best practices for modern software delivery, in topics including continuous improvement (CI), deployment patterns, security, DevOps culture, microservices, containers and more.
Out of the 50 episodes that have aired to date, featuring more than 150 guest speakers, below are 10 of our favorite recent discussions:
“In the microservices world, individual features might end up being their own services that are completely well understood”
– Daniel Rolnick, Yodle
Microservices are all the rage right now, and the industry is still learning, experimenting and developing patterns, for successfully designing, deploying and managing microservices in the real world. Are you considering jumping on the microservices wagon? Learn from experts at Kik, Yodle and Semaphore, as they share their journey and learnings from decomposing their monolithic application into microservices. Featured Panelists:
Daniel Rolnick
Daniel is the CTO of Yodle, a SaaS platform for small businesses, where continuous delivery is a way of life. @YodleTech | www.yodletechblog.com
Darko Fabijan
Darko is co-founder of Semaphore CI, helping teams deliver software faster. He currently is focusing on scaling Semaphore team and architecture. @darkofabijan | semaphoreci.com/blog/
Usman Ismail
Usman is a server and infrastructure engineer, with experience in building large-scale distributed services on top of various cloud platforms. @usman_ismail | techtraits.com
“When you treat configuration like first-class citizens, only then can you have your deployment product succeed because your product depends on the deployment configuration being right.”
– Juni Mukherjee, author of “Continuous Delivery Pipeline – Where Does It Choke?”
To enable fast, reliable releases, deployment automation is a must. This episode discusses the prerequisites and best practices for automating your deployments and ensuring zero downtime and fast mean time to recovery (MTTR) when deploying large-scale mission-critical apps. We also talked about the key differences between the first-generation of deployment automation and deployment automation 2.0, and riffed on what we have to look forward to for the next iteration of deployment automation 3.0.
Robert Firek
Software craftsman at Codurance. Devops engineer. Java programmer. Agile practitioner. He strives to create software according to the rule, “Simplicity is the final achievement.” @robertfirek | codurance.com/blog/author/robert-firek/
Paul Reed
Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec, and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity and human factors. @jpaulreed| jpaulreed.com
Taco Bakker
Taco previously worked as a Team Lead for a large international bank, spending most of his time bridging Dev and Ops. Today he’s a LEAN Six Sigma black belt focusing on CD. @tsbakker65 | www.tsbakker.nl/taco.html
Continuous Discussions (#c9d9) Podcast: Episode 43 – DevOps and CD for Non-Web Applications
“Firmware is updatable and I think the whole notion of being responsive to change is ultimately a very powerful characteristic of firmware and one that ultimately, along with the performance you get from it, is going to be an important part of solutions as we go forward.”
– Stephen Hendrick, ESG
If you think that DevOps is only for web apps, think again! Some of the largest organizations in the world focused on hardware manufacturing, embedded systems and IoT are proving the value of DevOps for the delivery of complex physical products that are integrated with software components. Watch the podcast to explore the differences between continuous delivery for webware and firmware, and listen to panelists discuss the challenges and patterns for successfully implementing DevOps for non-web apps.
Featured Panelists: J. Paul Reed
J. Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec, and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity, and human factors. @jpaulreed | jpaulreed.com
Continuous Discussions (#c9d9): Episodes 29 and 45 – Security & Compliance as Part of Your DevOps Processes
“In order for you to audit and trust the system, you need to make sure the system hasn’t changed over a period of time. Have a test that shows whatever you put in, the results that come out are predictable.”
– James DeLuccia, PwC
Listen to expert panelists explain how to bake-in security and compliance to your DevOps processes. Find out how DevOps and automation can help you pass your next audit. Key focus points include what it takes to get everyone on board with DevOps; how automation equals auditing, with some discussion on industry-specific regulations and compliance requirements; and how to enforce security for the code and for your environments and configuration.
Jonathan McAllister
Jonathan has been creating automation software since he was a child. Professionally he leverages 10+ years of experience in software development, test and delivery practices. He is an author, automator and business consultant. @jmcallister80 | www.masteringjenkins.com/
“The safest environment is the one you don’t let humans muck around in.”
– Martin Cron, WiserCare
Featured Panelists:
Andreas Wittig Cloud Specialist. Author of “Amazon Web Services in Action.” Software engineer, speaker, teacher and consultant. @andreaswittig | cloudonaut.io
Dave Bechberger
Senior architect and developer with a passion for delivering solutions to challenging problems in difficult domains from concept to delivery. @bechbd | experoinc.com/author/dave.bechberger/
J. Paul Reed J. Paul Reed has over 15 years’ experience in the trenches as a build/release engineer, working with such companies as VMware, Mozilla, Symantec and Salesforce. He speaks internationally on release engineering, DevOps, operational complexity and human factors. @jpaulreed | jpaulreed.com
Sukhbir Dhillon
When Sukhbir isn’t coding, dreaming of automation or being the founder of Addteq, he is at home playing with his 2-year-old daughter. @addteqsukhbir | nebula.addteq.com/blog
Continuous Discussions (#c9d9): Episode 21 – Implementing a DevOps Culture
“One expectation I like to lead the conversation with is, if you are a non-trivial software business, then guess what? You are in competition with every other software business in the world. So, you have two choices: evolve or die.”
– Aaron Lee, Pythian
This podcast offers tips, best practices and real-world examples of how organizations can navigate the cultural shift to Agile, DevOps and continuous delivery—from the leadership’s perspective, as well as at the teams’ level. Hear expert advice on how to facilitate silo-busting and system-level thinking and how to encourage experimentation, support a blameless culture, constantly practice for game day and more.
Featured Panelists:
Aaron Lee
VP of Transformation Services at Pythian. DevOps practitioner committed to creating successful business outcomes for clients. @observator | www.pythian.com/blog
Alon Becker
DevOps architect at AOL. Alon is involved in DevOps transformation at several companies, both startups and enterprises. @alonbecker
Mike Kavis
VP/principaI architect @ CloudTP Analyst at Forbes and The Virtualization Practice. Author of, “Architecting the Cloud.” No hype, just lessons learned. @madgreek65 | www.cloudtp.com/insights
Randy Bias
Randy Bias, VP Technology, EMC former founder of Cloudscaling (acquired by EMC) and director at the OpenStack Foundation. @randybias
Robert Kalweit
Certified ScrumMaster with 7 years’ experience and an Agile mindset that helps to execute tasks efficiently, on time and with personal heartiness. www.kalle-online.net/blog/agile
“While there are multiple approaches for implementing an internal Dev/Test cloud, you need to make sure that you pick a solution that is adaptive.”
– Kelly Looney, Skytap
The need to speed up feedback loops, simplify dev/test processes and collaboration and also save on infrastructure costs has led many organizations to create a private Dev/Test cloud to standardize their processes, tooling and environments across teams. This podcast takes a deeper dive into some of the challenges and prerequisites for enabling a self-service shared platform for the software delivery pipeline across dev and test, and some tips and best practices for getting started.
Phil Dougherty
Phil has over 10 years of experience building the backbone of the internet, from multi-continent private cloud environments to fully automated public cloud infrastructure powering mobile commerce APIs. @phildougherty | blog.containership.io
Continuous Discussions (#c9d9) Podcast: Episode 36 – ITIL and DevOps
“Take a user-centered design approach to everything you do.”
– Jeff Sussna, DevOps writer and speaker
During this discussion, we uncovered the similarities and differences between ITIL and DevOps, and discussed tips for how to align the two methodologies in an organization.
Featured Panelists:
Jan-Joost Bouwman
Jan-Joost works at ING as ITSM process owner, adapting ITIL to an Agile Way of Work. Previously he worked in various roles in systems development. @JanJoostBouwman
Kaimar Karu
Head of ITSM at AXELOS – custodians of ITIL & PRINCE2 / President at #itSMFEstonia / Service Management enthusiast / Beer sommelier / Food writer @kaimarkaru | www.axelos.com/news/blogs/
“The way we build software when it’s always releasable is fundamentally different than when we build to a release. The flexibility and agility comes from building it iteratively—where you’re always able to go in and change it. That, I think, is the main advantage of CI and CD.”
– David Bernstein, To Be Agile
Panelists review some of the metrics that matter for the different stakeholders throughout the software delivery pipeline. Learn best practices for some of the metrics that you should be monitoring to track your DevOps efforts, and—equally important—some of the metrics you should abandon.
David Scott Bernstein
David helps teams adopt practices such as test-first development and refactoring at hundreds of companies around the world. David is also the author of, “Beyond Legacy Code.” @ToBeAgile | tobeagile.com/blog/
Ketil Jensen
Ketil is a passionate learner and practitioner, always looking for better ways to work. Loves to help organizations continually improve. @ketilj | ketiljensen.wordpress.com
Continuous Discussions (#c9d9) Podcast: Episode 32 – Orchestrating Your Testing Suite
“If you can test it underneath the UI, you probably really should be testing it under the UI”
– Chris Kent, BTI360
Get an in-depth review of best practices for orchestrating enterprise software testing. Panelists discuss some of the challenges and proven patterns used to test critical software quickly and efficiently: What does your test matrix look like? How do you define the pathway through your test cycle? How do you use automation and service virtualization? How do you manage test environments and data? And more.
Featured Panelists:
Alex Cowan Alex has been an entrepreneur (5x) and intrapreneur (1x). Currently helping create digital innovators @DardenMBA & advising companies. He talks too much. @cowanSF | alexandercowan.com/blog/
Chris Kent
Chris loves crafting enterprise apps with ATDD, TDD and clean coding. You’ll also find him reading, outdoors or at a local brewery/winery. @thirstydev | www.bti360.com/author/chris-k/
Hugo Hendriks
Hugo is a freelance integration consultant based in the Netherlands with the focus on Oracle Fusion Middleware, Java, open source and Scrum. @R3DR0CK | www.redrock-it.nl
Kate Abrosimova
Director of content at Yalantis and tech journalist, who likes to create things, write about technology with a focus on mobile and collaborate with tech teams. @kateabrosimova | yalantis.com/blog/
“The pipeline is not so much about ushering code out to production, it’s finding ever opportunity to reject a harmful change prior to letting it get into production. So, the pipeline is an essential part of risk management.”
– Michael Nygard
To get to CD, applications and delivery pipelines must be architected in a way that supports the more frequent pace of smaller, incremental releases. On this episode, we discussed some recommendations for constructing a flexible, versionable, reviewable, test-able, revertable and resilient application architecture and CD pipeline.
Featured Panelists:
Aater Suleman CEO of Flux7, helping companies use AWS infrastructure to improve business agility and continuity. Flux7 deploys web apps across various technology stacks. @FutureChips | blog.flux7.com
Graham Smith
Dr. Graham Smith is head of software engineering at the UK Hydrographic Office, championing continuous delivery by day and blogging about it at night. @GrahamDSmith | pleasereleaseme.net
Marcus Rehm
Software engineer and business intelligence developer for Odebrecht Ambiental. Agile and Automation enthusiastic that always is looking for ways to improve products and process. @marcusrehm | marcusrehm.github.io
Melvin Laguren
QA automation lead at Wrap Media. Melvin has worked at various start up and enterprise companies developing automated tests and working on CI/CD pipelines. He spends his “free” time speaking at meetups/conferences, teaching QA workshops and working on a weekly comic strip, www.melvinisms.com. @mlaguren | www.laguren.net
Michael Nygard
Michael works for Cognitect. Has written and co-authored several books, including, “97 Things Every Software Architect Should Know,” and “Release It!” @mtnygard | blog.cognitect.com/
With such great conversations, it’s certainly hard to choose…
Continuous Discussions (#c9d9) airs every other Tuesday at 10 a.m. PST. You can watch all previous episodes of the podcast and also subscribe on iTunes here.
About the Author / Anders Wallgren
Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings more than 25 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.
The main reason your company should load test its websites and mobile applications is to learn how the site performs so you can improve the user experience and make smart web infrastructure decisions. Sounds obvious, doesn’t it? Above all else, load testing is a learning experience that provides a wealth of insight into how your website performs from both a user experience and technical perspective.
How can it be done? Running a load test involves creating a small or large number of virtual users via programming script, running a simulation in which those virtual users access your site, and gathering information about how well the website performs under the traffic load.
How Your Website Operates and Why it Matters
If you are curious to learn more about how your website operates, contact a specialized load test company that offers load tests with up to 50 users for free over a 30-day period. Such a smaller test will provide insight into how well your company’s site performs for a typical user during light traffic situations. Free application monitoring tools often can be downloaded if your business does not already have one.
Longer load times hurt conversion rates: According to Amazon, every 100ms of page load time latency reduces sales by 1 percent. So your business could be losing out on 10 percent of sales because your pages take a second longer to load. Testers can learn all sorts of interesting things about how a site operates with varying virtual traffic loads.
Primarily, the load test tells you how long it takes a page to load on your site for users at different traffic levels. You can find out how quick load times are during normal, peak, spike and overwhelming use rates.
The load time data helps identify not only problems in your website code that could be slowing down individual pages, but also problems with the infrastructure itself. Load testing lets your business know exactly how much load times increase when the site gets busy relative to normal use. The tests also can determine how much traffic a site’s infrastructure can handle before load times get outrageously high—and when the site will crash.
Proximity Performance
A load test provider can offer testing from server locations all over the globe. A guest in Chicago visiting a site that is hosted in New York City may have fast load times, but Los Angeles-based visitors may have to wait an extra second for pages to load. This data can help your company make an educated decision when purchasing a content delivery network (CDN) service that mirrors content, so site guests farther away from the original host server have a better experience with your site. Look for a load test provider that can offer synthetic load traffic of up to 500 Gbps bandwidth and a million concurrent virtual users. Loads should be generated to your breaking point, and fast!
Get the Ideal Amount of Power and Learn How to Scale
Once your business is able to see how your site performs under various traffic loads, that information can help determine where the infrastructure needs upgrades at various traffic levels. This helps with capacity planning—the ability to scale different infrastructure elements to meet demand without wasting money on power that is not going to be used.
Running load tests on your company’s site will teach you invaluable information about how your site works so your customers can have a better experience with your platform. Improved website performance equals improved business.
About the Author / Sven Hammar, CEO, Apica
Sven Hammar is co-founder and CEO of Apica, a provider of powerful, best-in-class technology for testing, monitoring, and optimizing the performance of cloud and mobile applications. Mr. Hammar he has decade-long experience and expertise in web performance and web optimization, e-commerce, cloud services, IT entrepreneurship and the Internet. He is also a serial entrepreneur who has founded several successful IT companies over the years.
There is probably more trust in the world today than at any other point in history—not necessarily by choice, but because of our use of software to carry out almost every type of transaction. The use of blockchain networks brings visibility to those networks of transactions: Information about an asset that was once held by separate owners is changing to the lifetime history of an asset or transaction and is shared between all stakeholders.
For software developers, this means ensuring the integrity of a blockchain network is paramount. To that end, three key interesting aspects regarding continuous testing are emerging:
New approaches to business networks require the ability to test supply-chain business processes and transactions.
Reliance on shared technology ecosystems requires the ability to test APIs from multiple perspectives and to simulate the behavior of consensus.
Increased dependency of APIs requires the ability to test integrations at scale without affecting distributed ledgers in which any interaction is immutable (unchangeable) and final.
Project teams face an unprecedented demand for first-time quality while minimizing the impact of testing on the team’s delivery. To respond to this challenge, test teams are enhancing their capabilities so they can test:
Apps that integrate with a blockchain network;
Chaincode that manages the execution of transactions on a blockchain network; and
Provision and scalability of a blockchain network.
In addition to these new capabilities, proven continuous testing techniques and tools can be adopted to help the team deliver quality software into their blockchain ecosystem.
Test Entire Ecosystems
Using a blockchain network means an organization is redefining the structure of its business networks and processes, connecting distributed supply chains with a single transaction backbone. Projects need testers to minimize the risk of business disruption by validating every business process works across all stakeholders on the blockchain network.
Test State Early—Shift Left
In a blockchain ecosystem, the new paradigm is state-based communication, not message-based communication. The behavior of the state of an asset is influenced constantly by market, internal and regulatory changes, so projects increasingly are adopting Agile and DevOps practices to respond as quickly as possible. Shifting testing to the left on an Agile project means the team can test early, and those tests can then be reused continuously. Providing early, iterative feedback on quality at the time of development means fewer problems are found late in the life cycle, where their business impact can be severe.
Establish Technical Trust
One of the great things about blockchain technology is the potential to create greater transparency throughout an ecosystem. Trust is embodied in the transaction itself, which gives an important new role for digital systems of trust. Regulators and owners of a blockchain network must ask testers to validate the codification of contracts, compliance and certifications, which are then deployed into the blockchain network and embodied within the business transactions.
Use of blockchain technology will fundamentally change business processes and enable new opportunities. Success depends on the level of trust stakeholders have in the blockchain network and the blockchain ecosystem.
However, a blockchain ecosystem is an environment shared among different organizations, each of which has a stake in—and dependence on—the overall system. This means each organization must trust the other stakeholders to fully test any software that interacts with the blockchain ecosystem in a manner that will not impact the reliability of the overall system. As such, a blockchain ecosystem that has a culture and reputation of technical trust between the dependent stakeholders is more likely to be successful. Continuous testing brings trust throughout the blockchain ecosystem.
To establish technical trust in a blockchain ecosystem, ensure these four key things:
Your team can test when needed, not just when possible.
Required technical environment works as required to support the business flows.
Business processes and transactions run as expected.
Solution scales to the expected usage.
Benefits of Continuous Testing and ‘Shift Left’
Enabling teams to shift testing to the left means projects can test when needed, not just when possible. Continuous testing means an organization can deliver capabilities faster, respond quickly to ongoing changes and realize the value of transforming applications to utilize the power of a blockchain network.
Watch the webinar replay on how to implement quality checks as early as possible, run tests as often as possible and integrate automated testing with release management to minimize the complexity of deployment.
About the Author / James Hunter
James has spent a large part of his career architecting and implementing large-scale, distributed systems in the finance, public and defense sectors. He now leads a global business segment responsible for defining technology strategy then developing and implementing solutions for both IBM and clients. Mentoring and encouraging future technical leaders is important to James. He works with students of all ages and speaks in primary schools to universities to evangelize on the benefits of technology and the positive impact software can have on our society and the environment. He has a degree in Management Systems and he is a Chartered Fellow of the British Computer Society. Connect with James on LinkedIn/Twitter
As the CEO of WhiteSource, I regularly consult enterprises about building and enforcing their open-source security policies.
In the course of my consultations, I discuss open-source security protocol with many software companies and enterprises, and I’m often baffled by the fact that many organization aren’t boosting their software development performance and speed by bringing their development and operations teams together via DevOps. In fact, only 25 percent of enterprises are currently doing DevOps. I mean, if you were a CTO and someone said you could make your software development 200 times faster and reduce unplanned work/rework by 22 percent, wouldn’t you jump at the chance?
Now, I know DevOps still is not being implemented even though it has proven to improve deployment rates, so I shouldn’t be surprised that security isn’t joining the DevOps party. But I am. Just imagine the benefits of giving security the DevOps treatment. There’d be no more (or, at least, significantly fewer) last-minute security issues, no more unrealistic security policies, and engineers, IT and security professionals who actually understand each other and improve their own processes to work better together. This is the essence of rugged DevOps.
Implementing rugged DevOps is a huge decision for any enterprise, and it requires a lot of planning and time to implement. However, you don’t need to completely remodel your organization to start enjoying some of what rugged DevOps has to offer.
So, what can you start doing today?
Shift Left Your Security
DevOps is all about shifting left security to find security issues as early in the software development life cycle (SDLC) as possible. The earlier you find an issue, the cheaper and easier it is to fix.
So, how can you shift left your security? Start by integrating security tools into your continuous integration (CI) process to find vulnerabilities as soon as they’re added to your build and sometimes even your repositories. Tools exist that can integrate with your build tools and identify potential issues in your build.
Also available is a browser plug-in that allows developers to detect security vulnerabilities while they are searching for open-source components online. This tool helps developers say no to vulnerable components long before downloading or integrating them with their code.
Shifting left security is the hardest part of any enterprise’s rugged DevOps journey. Yet by taking some small steps, you can start to enjoy the benefits of DevOps with a twist of security.
Adopting a Micro Approach to Security
Just as operations has adopted a DevOps mindset to understand and become involved in development, it’s now security’s turn.
Security needs to stop being on the outside of development, looking to control it through detailed security policies. Instead, it needs to take an active part in it, steering it toward security. Security can do this by focusing on understanding development and deployment processes, and searching for possible quick wins.
From my own experience, every time a security team takes the time to understand the peer code review process, small changes are made with significant contribution to code security.
I also often notice that security teams are unaware that some developers may still use the old “copy and paste” method in using open-source components. This makes it impossible to track known open-source vulnerabilities. Once security teams understand this, they can improve guidelines to ensure they are not blindsided.
The good news is you don’t have to overhaul your whole organization to give security a micro-makeover. Your security team simply needs to start getting into the finer details rather than planning long-term security programs and road maps.
Speaking the Same Language
A good sign that an enterprise is doing DevOps is when developers and operations call software issues by the same name. This means the two teams have defined their issues and objectives together, and are working toward joint goals. The same is 100 percent true for rugged DevOps.
If development sees a problem in terms of unplanned work, operations sees a glitch and security sees a vulnerability, collaboration will be very difficult. Introducing a shared vocabulary for issues throughout software development is an effective way to get your professionals on the same page.
With this shared vocabulary, development and security can sit together and define shared key performance indicators (KPIs). For example, development’s goal of faster deployments can be linked with security’s aim of reducing mean time to release (MTTR). Once each team knows what the other wants to achieve, they can understand how to help each other.
At the end of the day, security is more likely to be taken seriously if it is understood. And this is key. With the typical enterprise ratio of 100:10:1 development, operations and security professionals, security needs all the friends it can get.
Ready to Try Rugged DevOps on for Size?
As you can see, you don’t need to turn your enterprise upside down or even have a rugged DevOps team to start getting some of its benefits. Just follow these three steps, and your enterprise can get a taste of what rugged DevOps has to offer.
So what about you? Are you ready to take rugged DevOps for a test drive?
About the Author / Rami Sass
Rami Sass is an experienced entrepreneur with deep background in R&D and product management. At Eurekify. and later CA, became an expert in designing and implementing complex security management and compliance software systems, and in delivering them to the market. Currently he is co-founder and CEO of WhiteSource.
John Yeoh is the Senior Research Analyst for the Cloud Security Alliance (CSA) working within industry working groups, SDOs and strategic relationships in the development of cloud security standards, tools and solutions and strategy development. With over 15 years in research, John has authored reports on IT, cybersecurity, cloud and new technologies. His thought leadership has been presented in SC Magazine, USA today, Information Week and others, and he currently sits on numerous technology committees in government and industry. John’s graduate studies include Massachusetts Institute of Technology and University of Southern California with undergraduate work at Eastern Washington University and University of Washington. Connect with him on Twitter and LinkedIn.
Robert Hawk serves as Information Security Expert at xMatters, Inc. He has extensive experience in information systems security, computer security, cyber security, information assurance and governance, risk, and compliance (GRC) management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on 
I found the most honest discussions were a floor up and a bit removed from the topics discussed in the main ballroom. These discussions were given the informal title of “Open Spaces” and were run in a typical un-conference format. These conversations were the real opportunities to learn about the stresses of implementing the modern portmanteau of DevOps.
Orlee Berlove is the Marketing director at 
Phil Trainor is Head – Security Business, APAC at 
Randy Apuzzo is founder and CEO of Zesty.io, the SaaS CMS Company. At age 12, Randy was hacking corporate sites and crashing systems for fun. As an adult, he applies his computer science and branding background as an industry visionary, architecting scalable solutions that help companies accelerate and scale their global digital content strategies. He is revered for empowering businesses with technology that grants agility, cost savings, security and increased market share. To connect with Randy, please visit 
Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings more than 25 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.
Sven Hammar is co-founder and CEO of 
Rami Sass is an experienced entrepreneur with deep background in R&D and product management. At Eurekify. and later CA, became an expert in designing and implementing complex security management and compliance software systems, and in delivering them to the market. Currently he is co-founder and CEO of WhiteSource.