Tim Prendergast (@auxome), Evident.io founder and CEO, answers five questions all about security. He covers everything from security poverty, to new vulnerabilities introduced as companies shift to cloud architecture and new exploits we are likely to see as we consume more services through APIs. Before Evident.io, Tim was an architect at Adobe, leading the Cloud Architecture & Security Team for the Creative Cloud initiative. Find out all about him at http://about.me/tprendergast.
1. You were part of one of the most dramatic technology pivots in recent memory at Adobe – a shift from shrink-wrapped software to the Creative Cloud, which is a service. What was the most difficult part of that shift? What did you take away from it that led to Evident.io?
The hardest part was educating such a diverse engineering organization on the perils and benefits that the cloud offers. When you’ve spent decades building software and selling it in boxes to run on standalone computers… that model is the polar opposite of today’s electronically-delivered software and services experience.
We had some things easy — Creative Cloud ran software locally, which was one of Adobe’s tenured strong points. However, the most powerful aspects are how Creative Cloud’s applications can take advantage of the amazing cloud-based services to store, manipulate, and co-work on digital assets.
The friction started when teams were developing Web services for the first time, and had to face the integration of security capabilities – without derailing the go-live of new services. We spent a lot of time working with individual teams on critical scalability and security concepts. In fact, I had a checklist 200 items long that we would go through with every team before we sent them out into the cold, cruel internet.
We learned a lot about how hard it is to transition traditional organizations to a DevOps state of mind — every team perceives the path to completion differently, with varying results. We saw a set of parallel universes form and collapse, as every possible iteration played out.
Only a select few survived. We saw how critical certain approaches were to the success of organizations using programmatic infrastructure:
- Heavy use of API-based tools: We wrote some, we used some, and we bought some tools that tapped the AWS APIs to help us get away from manually engaging the API for various actions.
- Highly visible and accessible telemetry: We built dashboards and tools to give us at-a-glance decision-making capabilities. Do we have enough of machine role X for traffic of Y? If we didn’t, the web page often had a button we could scale up/down with.
- Leveraging economies of scale: We were more powerful working together than apart. We could combine budgets between teams and buy the best-of-breed tool, rather than buying 2 sub-par tools.
Evident.io really is the amalgamation of the capabilities and tools we wished existed in the cloud security space, but just weren’t available. We see Evident.io filling that security gap in the same way that Chef or Puppet did for configuration and system state management.
2. Small companies and open source projects don’t always have the resources to build a formidable security infrastructure – what sorts of things should devs prioritize highest?
Your job in security is to be less attractive to the general attacker, and more responsive against the motivated one. Your job is to put a big, obnoxious sign up showing potential attackers that you aren’t a pushover, and they will tend to move on to easier targets.
Start with a proper architecture diagram of what you are building, and make sure it is as accurate as possible. This represents the basis upon which you layer your security approach – the most fundamental being:
- Perimeter security declared by the required inbound and outbound traffic flows REQUIRED by your application/service/infrastructure.
- Host-based security mechanisms defined by system roles and needs – this can be host-based IDS/IPS, host-specific firewalls (iptables, EC2 security groups, etc), file-integrity monitoring, log collection, and various other types.
- Data security for data as it is in-flight between systems, data protection mechanisms for data at rest (encryption, replication, access controls).
The best thing you can do is to document your system well-enough to guarantee you understand it, and spend the rest of your time formulating a response plan. Let’s be honest, you will never outsmart the attackers 100% of the time. When you finally do lose that battle of wits, you need to be prepared to act, and do so intelligently.
3. As more and more APIs are made public and businesses make APIs a central part of their product, what dangers do you see? Are there going to be new sorts of attacks?
There are far too many APIs being cranked out in such a short period of time… there is no way that they have all been properly secured and built. There will definitely be new attack vectors in an API-centric Internet, but we are still too early to know the pervasiveness of such attacks.
4. You went from an architect leading a big team of engineers in a huge company (Adobe), to founding a company with a friend. What was the hardest part of making the move, and what would tell other engineers in big companies that are thinking of starting something?
Fling yourself into the abyss with the rest of us crazies. Honestly, you give up some predictability for a constant rollercoaster of emotion. A key tipping point for us was socializing the idea amongst various industry veterans, personal advisors, and spouses. We were receiving strong positive signals from all of them. That was a powerful moment in our lives, and great validation that we were ready to make the transition.
As much as we loved what we did at our former jobs, at Evident.io we have laser-like focus on building a new security platform for the masses. That is something we never could have achieved had we tried to do it while employed by a big company.
5. You worked on data storage and sync technologies in several roles. Where are the NoSQL databases doing things right, and where do they need to improve?
I believe the most powerful feature of the NoSQL product ecosystem is its schema-less design. We are arrogant, ignorant engineers when we think that we can design a long-term schema up-front. The schema changes that come later, especially at scale, become such a painful problem that NoSQL earned its stripes on this merit alone (in my opinion).
I think the general industry approach is solid — developer-centric, open-source, enterprise support/features, and the broad language support through client libraries. The most pivotal area of improvement for me would be in the test and architecture side of the equation. I believe NoSQL vendors should be doing a lot of tests, and releasing them into the wild for interpretation/review/applause. Nothing irritates me more than getting a fresh drop of a NoSQL product, deploying it, running some basic benchmarks, and watching it fall over dead. If the product can’t even pass my basic smoke tests, how can I even fathom using it for a real purpose? I believe we’ll likely see community-driven benchmarking long before we see the vendors step up, but I’ll cling to eternal optimism.