Candid Ranks on the Inc. 5000 for Fifth Consecutive Year

Achievement Validates Firm as one of the Country's Fastest-Growing Cloud Consulting Firms

Candid ranked on the Inc. Magazine’s 38th Inc. 5000, the most prestigious ranking of the nation’s fastest-growing private companies. This year’s ranking marks the fifth year in a row the cloud consulting firm secured placement on the list since its debut in 2015 with a 3 year growth rate of 79 percent. Candid is one of 2019 Georgia companies recognized on this year’s list, and one of only 15 to consecutively rank for the past 5 years or more

“We’re honored to be recognized as part of an exclusive group of fast-growth private companies demonstrating aggressive yet consistent year-over-year growth,” says Merrick Olives, founding partner of Candid. “There are very few companies with a showing like ours in the IT Management industry on the list.  Our placement validates both our consistent delivery and discipline for clients. As a leader in the cloud community, we’ve got our finger on what’s to come as more enterprises migrate critical applications to the cloud.”

Candid differentiates itself by providing regulatory compliant solutions that no other firm is currently offering. With a growing adoption of cloud technology by healthcare and financial service organizations, Candid is well positioned to lead these industries to harness the business advantages of the cloud.

“Our capabilities are a natural fit for these markets. It’s simply a matter of time before adoption becomes widespread, and our hopes are to scale our offerings on a national level as soon as possible,” adds John Peak, managing partner for Candid. “Up to this point, Candid focused primarily on the Southeast Region. Given our growth and broad exposure as an innovator in the cloud space, we are fully committed to scaling the company nationally to support our increasingly geographically dispersed client base.”

“Congratulations to Candid on being included on the Inc. 5000 list for five consecutive years,” notes Sonny Deriso, Chair of the Georgia Chamber of Commerce. “We are honored to play a role in Candid continued growth and join them in celebration over this milestone achievement. We look forward to many more years of applauding their continued success.”

For more information and the full list of 2019 Inc. 5000 rankings, visit


Lessons Learned from the Capital One Hack: Compliance in the Cloud

When federal prosecutors charged a Seattle woman with stealing data from more than 100 million credit applications this week, the security of the Capital One AWS environment became the immediate focus of the media landscape.

According to the court filing and various media reports, the attack vector was orchestrated from a compromised server due to a misconfigured web application firewall (WAF). Ephemeral AWS credentials were extracted from the instance role and used to raid data from S3 buckets. The attack took place on April 21st, and on July 17th an email to Capital One outlining the attack sparked an investigation.

Several things immediately stand out about this attack. Most notably:

  • The weakness identified by Capital One and throughout media was "a misconfigured firewall." But even if that was the point of entry, a single firewall misconfiguration should not cause a security breach this vast; as failsafe security measures should catch intruders. The lack of redundancy in security indicates other systemic security issues.
  • As Capital One acknowledged, the web application firewall (WAF) role in question never made API calls, like “List Buckets” or “Sync”, until this criminal made those calls. The WAF role’s permissions should have been reviewed at creation time to make sure they fit the business purpose.
  • Nothing in the system flagged the WAF role’s behavioral change, though such warnings would’ve been possible. When a credential set suddenly begins behaving atypically – such as scanning and looting S3 buckets – it’s wholly possible to flag the behavior for review. The API-driven nature of public cloud allows you to be reactive in real-time; Amazon Macie could have caught this abnormal behavior and alerted Capital One immediately.
  • A broader security architecture review should have highlighted that extra S3 permissions and eliminated them from the role, or limited them to a WAF-logging specific bucket if truly needed.  New automation tools exist to help meet this level of compliance. Why weren’t S3 buckets filled with sensitive information on restricted access for known IP ranges only, when such a setting can be managed and continuously monitored with automated compliance tools?
  • Permissions should be regularly checked to see if they’re being used. If not, those extra permissions should be removed. Netflix recently released an open source tool to automate this effort, called RepoKid.
  • As a best practice, logging must always be enabled across all public cloud accounts, and those logs should be sent to a protected and dedicated logging account.
  • It’s imperative to have an Incident Response plan, so you know how to react to compromises before they happen.

On the last two points, Capital One was actually pretty successful. Because Capital One was proactively logging everything, the criminal’s actions were logged and available for immediate review. You can’t protect what you can’t see, and at minimum Capital One was able to look retroactively and see the exact steps taken to breach their security, allowing them to be rapid and accountable in their response, which is commendable.

In the end, the lesson from the Capital One breach should be a lesson of caution that the public cloud, while far more secure than on-premise data centers, is far from a security silver bullet. It’s imperative that the DevOps teams building your public cloud are paying attention.