A takeaway for us is if you're going to use security documentation and policies as marketing, you need to keep it up to date and consistent with the rest of your security documentation. Lots of companies are promoting what they do for security as a way to build trust with website visitors and the market. It's a double-edged sword.
In my experience, security policies often start short, readable, digestible, and actionable. Over time this changes as more and more people / groups add to them or edit them for specific purposes - engineering, privacy, HR.... New hires come in and make changes. Policies just evolve.
To me, the worst culprit is audits. During an audit, there's this tendency to continually add to policies to bring them in line with the framework you're being audited against, or to bring them in line with what your auditor interprets as required by the framework. We used to host our policies on Github and you could clearly track our audit season by the revision frequency. In a week with an auditor, we'd have 10 or 50 or 100 revisions to policies.
Over time, what you end up with is a Frankenstein set of documents that are not short, readable, digestible, or actionable. But they helped you pass your audits.
This is not how it should be done but this is the reality I've seen.
At my last company, we wrote and open sourced policies that many people used to pass audits - https://github.com/globerhofer/HIPAA-policies. I don't know if much of the policies were relevant to sec ops for those companies but the purpose a lot of the time was the audit.
I really get mad at peoples bias towards adding more “to be safe”. More security policies, more restrictions, more alerts, more process, more everything. The very fact that many audits apparently exist to ensure you have a shit security policy by bloating it with nonsense and crap is ridiculous. It’s all insanity.
A classic example is password reset policies, a rule that makes security worse by burdening its users in ways that predictably and reliably make them use the lazy way to do things. In general you get good security by investing in it and hiring careful people, not by writing a list of 10000 rules and exclaiming “if only you followed rule 7354!” when something happens. Security policies seem to be designed like horoscopes, designed to address any possible variation of a security incident that might happen, rather than truly pointing you towards what’s important.
Security audits don't exist to ensure you have a shit security policy... I think it goes without saying that's untrue.
If a particular standard or framework you need to meet requires these things there's unfortunately not much your auditor can do. As such, your problem is with the standard or framework you're aligning with not so much the auditor.
If a security standard requires you to have a reset policy, then you should have free reign to design that how you see fit in the context of your organisation and its compensating controls.
At Catalyze we're building the underlying infrastructure for some of the most exciting and innovative technology companies in healthcare. In short, we provide a compliant platform and data services to power the scaling of digital health. We love working on open source, solving difficult problems and we're growing rapidly.
Over the last 2 years we’ve grown our team from just a few to over 20 full-time employees. During that time raised over $6m in venture capital, and signed some of the biggest brands in healthcare (the VA, Amgen, Blue plans, and many more).
Our team and board is made up of experts in healthcare, security and compliance, data control, and cloud engineering. We have several levels of engineering positions open including a Healthcare Integration Engineer, Junior - Senior Software/Systems Engineers, Network Engineers, Support Ops and several other non-technical roles. For more info - https://catalyze.io/jobs
I'm Travis, one of the co-founders of Catalyze - https://catalyze.io. We also offer a HIPAA-compliant platform-as-a-service (PaaS). Our compliant PaaS starts at $500/mo and includes dedicated, encrypted logging, monitoring, backup, disaster recovery, and encryption (at rest and in-transit). We've been through 3 3rd party audits + penetration testing (most recent audit we were 100% in compliance). We're very transparent about HIPAA and open our audits up to customers to use as part of their sales collateral. You can see how we interpret and address HIPAA requirements here - https://catalyze.io/hipaa/ - and you can see our policies here - https://catalyze.io/policy/ (we're open sourcing these in the next couple weeks).
We don't provide policies or risk assessments as a service, but Accountable (http://accountablehq.com/) does a great job with those. Using Catalyze + Accountable starts at $600/mo, about 1/6th of the starting price on the Aptible site; we also offer 60 days to terminate so don't lock you into annual contracts to get that pricing.
We've got some great production customers, with testimonials and use cases on our site, that love our service and support, and have moved over from hosting providers like AWS, Firehost, and Blue Box. I'm happy to answer questions about Catalyze and the compliant cloud space in general.
Dude, you shouldn't shill on someones product launch especially since you're not providing meaningful feedback on how your product differentiates itself from Aptible.
I thought it was an informative post. Most people upvoting this thread is probably doing so because this is really a great/unique/useful product idea. Finding out there are other products in the same space is useful.
Have to disagree actually. We make seed investments in health it startups and when I came across this, I thought to myself it's a great idea, much needed. But I also wondered who their competitors might be, if any. Posts like this are helpful in that way. Perhaps it could have been written with a little more humility.
A takeaway for us is if you're going to use security documentation and policies as marketing, you need to keep it up to date and consistent with the rest of your security documentation. Lots of companies are promoting what they do for security as a way to build trust with website visitors and the market. It's a double-edged sword.