Welcome!

Cloud Security Authors: Zakia Bouachraoui, Yeshim Deniz, Terry Ray, Liz McMillan, Pat Romanski

Related Topics: @CloudExpo, Cloud Security, @DevOpsSummit

@CloudExpo: Blog Feed Post

Why Your Code Isn’t as Secure as You Think (And What You Can Do About It) | @CloudExpo #Cloud

For any given bit of code or corresponding bit of functionality, how many people really know what's going on?

Why Your Code Isn't as Secure as You Think (And What You Can Do About It)
By Erik Dietrich

How well do you know your code?

It sounds like a strange question, but please indulge me.

Maybe you're a manager or business analyst. If this is the case, you ‘know' the code through a translation layer in which the developers in your organization explain what it does. Sometimes you can see what it does by interacting with it as a user or by reading incident reports.

But to really know and understand what it would do - to have a grasp on how it will behave in an arbitrary situation - you need one or more developers to give you an explanation.

Maybe you're a developer.
In this case, you don't need a translator.  If you've written the code, then, presumably (hopefully), you can explain how it works in arbitrary situations. If someone else on your team, in your group, or from your department has written the code, you might not know it quite as well. But, with a bug report, an afternoon, and your IDE, you could figure it out. That's assuming, of course, that you have access to the code and some reason to look at it.

Depending on the size and scope of the codebase or codebases that the company has in production, any given developer may be utterly and permanently clueless about some corner of the application. For any given piece of code, someone knows something about it, assuming the author has not departed the company, but the knowledge coverage may not be especially deep.

For any given bit of code or corresponding bit of functionality, how many people really know what's going on? Could it be fewer than you think? Maybe just one person? Maybe even... no one, in the event that the original author has long since departed?

The danger of shallowness of knowledge
Cisco recently announced the launch of an internal code review. This was done in response to Juniper performing a similar sort of internal audit and discovering code that would allow secret, remote access to its firewall products. The linked article makes allusions to the NSA and some pretty cloak and dagger stuff, with it not being known at the time of writing how this code found its way into production.

I can tell you from my own experience that such a thing would be appallingly easy, in some situations. I've personally been in situations, particularly at smaller companies, where I was the gatekeeper between the codebase and production deployments. I could literally have sneaked a condition into the codebase that appended "|| password == ‘Erik'" that would have given me carte blanche access to a production system for as long as I worked there and quite possibly long after I'd left.

Of course, I've never done any such thing. And frankly, I doubt too many developers have either. If a developer were going to do something like this with any sort of ill intent, I suspect that he'd be a lot more clever about it. The resultant code would almost certainly be subtler and come along with plausible deniability. "Oh my," he would later say if confronted, "I can see now how that BUG would allow someone admin access - I had no idea!"

I have never done such a thing, nor have I ever been tempted.

But the fact that it would have been possible for me to do it easily is a huge process smell. It indicates that there is a perilous shallowness to knowledge of the code. You typically see this in small, understaffed shops where the development team is spread quite thin. But no one is really immune - it just takes that one module that no one but Alice really knows too much about.

This situation is so dangerous precisely because there are all manner of ways that Alice as the only link in the chain can break. Maybe she inadvertently opens a security hole. Maybe someone socially engineers her somehow to inadvertently open a security hole. Maybe she's paranoid about being fired and builds in an ‘insurance policy.' The list goes on. But if Alice is the only one with eyes on what Alice is doing, weird, unpredictable, and problematic things could be brewing.

In short, and to return to my earlier question, you don't really know what your code is doing if you have to take a single person's word for it.

Code review to the rescue
It should surprise no one that the solution to this problem is an all-hands-on-deck audit.

There is no faster way to increase the organizational knowledge depth of the code than to bring in an army of people to read, review, understand, and question existing it. To appropriate Eric S Raymond's famous quote, "with enough eyes, all backdoors are visible."

But this sort of Herculean effort is extremely costly and evokes the phrase, "closing the barn door after the horse has escaped."

Throwing a lot of people at a massive code audit is expensive both in opportunity cost and in wage cost because at least some of them will presumably need knowledge of the codebase. It's also probably the case that your reputation has suffered a hit and that you're scrambling to cover yourself. This is not only wholly suboptimal, but easily preventable.

All that's necessary is a culture of regular code review. On the surface, code review seems like a costly exercise that's often a luxury. After all, each hour spent reading someone else's code is an hour that the engineer could be writing new code. This argument, however, tends to fall apart quickly on deeper inspection.

Code review is one of the most effective ways to reduce defect counts, and that alone probably recoups the return on investment. But a subtler, more germane benefit is that code review promotes a culture of collective code ownership.

Collective code ownership is the idea that there isn't "Alice's module" and "Bob's module." Members of the team do not silo and do not own code. They work on one section of the code or one feature, and then move on to a different one. They collaborate heavily on all code being written, through pair programming and/or code review. This creates a culture in which the team owns the code. And when the team owns the code, the possibility that any one developer will take out an ‘insurance policy' becomes orders of magnitude smaller.

Anyone with a stake in production software worries about their code. Does it do what it's supposed to? Does it perform well? Does it look good? How safe is it? There are few easy answers when it comes to questions like this.

But when it comes to the safety of your code, you have the good fortune of a no-brainer at your disposal: create and nurture a culture of code review.

Read the original blog entry...

More Stories By SmartBear Blog

As the leader in software quality tools for the connected world, SmartBear supports more than two million software professionals and over 25,000 organizations in 90 countries that use its products to build and deliver the world’s greatest applications. With today’s applications deploying on mobile, Web, desktop, Internet of Things (IoT) or even embedded computing platforms, the connected nature of these applications through public and private APIs presents a unique set of challenges for developers, testers and operations teams. SmartBear's software quality tools assist with code review, functional and load testing, API readiness as well as performance monitoring of these modern applications.

IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...