Minimal Viable Compliance (MVC)
In our prior posts, we explored what compliance is and the challenges that organizations face. As no two organizations are alike, this led us to the question: What are the absolute essential policies that transcend all regulations and are best practices for any organization to have in place? This post will outline what policies and procedures an organization should consider before focusing on anything else related to compliance.
TL;DR
Compliance is hard, but it doesn't have to be. Do the following things, and you'll be well on your way to running a secure and compliant business.
- Map out where data enters, moves through, is stored long term, and leaves your organization.
- Define retention periods for every system that stores information.
- Have well-defined and tested system backup and recovery procedures.
- Ensure all systems employ encryption at rest and in flight.
- Protect all of your EASs with MFA.
Data Data Data
Whether it's client data, employee data, or potential employee/client data -- understanding the information you collect, who has access to it, and how/when it's accessed/used is essential for achieving MVC.
Data Collected/Managed
Even if it's a scribble on a napkin, start by listing all the information you take in to provide your clients with services AND all the data you ingest to operate your company. For a typical small to medium-sized company, it would look something like this:
- Potential Employees: Resumes and contact info via email or the website and then stored in an HRMS.
- Potential Clients: Email addresses and contact information collected from the website, email, phone, and networking events. Information is stored in a CRM. Tracking cookies are used to target potential clients on the website.
- Current Clients: Information gathered on our website including contact information and other non-public information used to provide services and goods.
- Current Employees: Sensitive information gathered via email and online forms during the onboarding process. Public information regarding their CV and qualifications. Highly sensitive non-public information used for payroll and healthcare services entered directly into the HRMS.
- Company IP: The secret sauce that makes your company valuable to others. For tech companies this is usually the source code that provides a service to the client, for a law firm this might be well-crafted legal templates, for a services company it's their internal knowledge base plus people, and for a restaurant it might be, well, an actual secret sauce recipe :)
Pitfalls
Most organizations focus on their IP as they feel it's the one thing above all else that will allow them to continue to grow and be profitable. Current client data is typically the second most protected data asset as a leak of that information could lead to a loss of business. The other data asset types are (typically) a very distant third for smaller organizations in terms of priority.
Regardless of the type of data we store, there are four mediums that must be secured in order to protect the vast majority of our data.
Email and Chat
By far, the greatest PITA as it relates to data leaks are emails and chats. It's a common attack vector for phishing attempts to compromise security and is a typical dumping ground for millions of pieces of employee PII, client data, client PII, etc. This storage medium is also a funnel and long-term storage mechanism for billions of employees around the world. Using email as a data dumping ground is a problem as it gives hackers access to a wealth of information should they gain access to a single system. It's also very easy to lose control of the data due to accidental forwarding of information or an overly curious/disgruntled IT system administrator.
In order to prevent data loss of sensitive information, Neosofia has adopted the following policies:
- All emails, without exception, will be deleted after 90 days.
- All chat messages, without exception, will be deleted after 90 days.
- All EASs must be accessed through MFA.
- An EAS that does not support SSO may be used if the data that it manages is classified as low sensitivity or publicly accessible.
- All systems must have multi-factor authentication (MFA) enabled. Authenticator apps with biometric verification are preferred for MFA with SMS as a fallback option if app-based MFA is not an option.
The email and chat policies act as a forcing function to put data where it belongs. For things like resumes, you need to put them into the HRMS, for client data the CRM, for system access credentials put them into your credential management solution. You still have the flexibility that email offers, but you have a finite amount of time to properly file information in its "well-managed" source of truth system. To put the policy implication a little more plainly:
A place for everything and everything in its place
-Benjamin Franklin
A place for everything and everything in its place behind systems protected by SSO, MFA, RBAC, EAR, AND EIF
-Benjamin Young
We understand that this may be a hard pill for many to swallow (M.A. I'm looking at you and your 25k JIRA messages sent over the last 15 years), but hear us out. When was the last time you actually needed an email more than 90 days old? 180? 365? If that email was deleted, couldn't you ask the sender to resend it? If it's a computer system that sent the email, just log into the system and look at the audit trail! Or perhaps you like to use email as a task or document management system -- might I recommend that you just use a task or document management system, or perhaps finish your to-dos in 90 days :) To be clear -- 90 days is aggressive, most large organizations have 180 or 365-day policies regarding email/chat retention. It's your company at the end of the day, but we strongly recommend putting some type of retention limit plus SSO and MFA policies in place. Or in the words of Elsa (Frozen):
The chat and email retention policies have the added benefit of limiting the legal discovery process to 90 days for both systems should your company ever be sued. Not that your organization would do anything illegal, it just makes the process of handing over relevant information easier as your legal team does not have to sift through years of unstructured emails and documents to determine if they're applicable to the lawsuit in question. We'll need some policies to retain emails longer than our 90-day limit to support legal processes, but that will be an advanced compliance topic for another day.
File Sharing Systems
Have you ever filled out a Google/Cloud Form for an employer, client, service provider? Did a co-worker ever ask you to share a large client database in Google Drive? Box? iCloud? When you shared the data, did you know who has access to the data? Just the one person? Are they able to share the data again without your knowledge? It's no surprise that file sharing systems are the second-largest source of data leaks and compromises. The situation with file sharing systems is slightly better than emails as you typically have better logging and monitoring for these systems and there is typically a robust RBAC system that can be used to manage the data. Despite the better tools to manage file sharing systems, we still need to have some policies in place to secure our data.
To help prevent data loss, Neosofia will adopt the following file-sharing policies:
- Once per year, all documents not accessed or modified for over 365 days will be archived for long-term storage.
- Once per year, all long-term storage documents older than two years will be purged. This policy does not apply to financial or legal documents that must be retained for more than two years.
- All file sharing activity will be logged.
- Well-defined system backup and recovery procedures will be established to protect against data compromise or loss.
- All documents and long-term storage mediums will be encrypted at rest and in flight.
- Decryption credentials will only be accessible to IT system administrators that are responsible for the system backup and recovery procedures.
Employee Workstations
Have you ever asked or been asked to watch somebody's work laptop while at a café? Did you ever have your device stolen from a café? Did you ever have your device stolen from a café and then a few days later all the sensitive client data that was on it shows up on the dark web for sale at a very modest 3.8 million dollars? Did you make your employer pay the bill or did you eat the cost to avoid the embarrassment of having to report the incident to your boss? Did you quit your job and flee the country?
To prevent data loss from an employee workstation, Neosofia will adopt the following policies:
- All company workstations will employ disk-level encryption to ensure all information is encrypted at rest.
- All company workstations will require username and password authentication to unlock the disk encryption.
- All company workstations will employ a 30-minute screen saver timeout to force re-authentication. For portable systems, lid shut events will force re-authentication and all employees that leave their workstation unattended must lock the screen in public spaces.
If you're working at a café and need to use the WC, just shut your laptop lid before you get up! We would rather pay 2-3K for a new laptop than a 2-3M ransom.
Workstations can also be compromised in less physical ways that we'll discuss in future advanced compliance topic posts.
The Cloud (raw Compute/Storage and 3rd party services)
If you're like most companies, you're probably using hosted services for functions like email, chat, project management, etc., powered by a major provider like Google, Microsoft, JIRA, Monday, or GitHub. These providers typically have achieved multiple regulatory certifications proving that they comply with an internationally recognized security standard such as SOC2 or ISO 27001. For Neosofia, we're going to KISS and establish a vendor qualification policy that will ensure the qualifications of the third-party service providers meet or exceed our own policies/standards/certifications.
When we define our vendor management SOP, we'll add the certifications step as a procedural check, but for now, let's just list all the vendors we've selected so far with the services they provide and a link to their certification(s).
As WebTrust does not meet the ISO/SOC criteria for qualifying a vendor, we'll need to a) document a planned deviation stating the risk associated with accepting a less rigorous security certificate or b) pick another CA that is ISO or SOC certified.
The GitHub certifications only apply to their enterprise cloud product. In future posts, we'll explore how using GitHub's pro and free plans could be a barrier to satisfying our ISO/SOC policy.
Just because these organizations have ISO/SOC certifications, it does not mean you have secure or compliant business operations. After procurement, these systems must be configured to satisfy your policies. Remember our MFA policy? Once a 3rd party provider is procured, you must configure the system. For GitHub, this means that we had to log into the configuration settings under our organization and enable MFA for all users.
This is just one setting out of hundreds that must be "correctly" configured across multiple systems to satisfy our policies. Future posts will go into more detail on how the Neosofia validation and evidence services can help guide your organization into ensuring you're complying with the regulations, but for now, it's a manual process to tick all the right boxes.
What's Next
We'll be adopting all the policies above into our official policies document and breaking them into three levels. The next post in our series will outline why we're breaking policies up into three levels and expand on our initial set of data integrity policies.
Footnotes
-
created using "DALL•E 3 XL v2" on Huggingface with the prompt: old bald guy running around singing the frozen theme song let it go with hundreds of pieces of paper flying around instead of snow and snow covered mountains in the background ↩