How to Stay SOC 2 Compliant

For many small- and medium-businesses, getting to SOC compliance is the biggest challenge on their radar. But it’s important to keep the longview and consider how you’ll stay compliant even after you’ve gone through your first audit. 

Practical Assurance has years of experience getting organizations to SOC 2 compliance and helping them maintain their programs. Read on to find out what to expect for an ongoing SOC 2 compliance program.

The Yearly SOC 2 Compliance Cadence

Once you’ve gotten through the process of defining and implementing your SOC 2 compliance program, you’ll find that your program can fall into a particular rhythm, hitting milestones on your checklist throughout the year. Defining this cadence is an important way to ensure that your organization stays compliant and addresses risks year-round.

The timing of addressing these processes can be mapped to semi-annual, quarterly, monthly, and even weekly due dates. For instance, larger questions of systems and overarching process reviews should happen every six months to ensure your team is on track. Systems that are more integral to your business processes, like malware, software, and risk assessment systems, should be reviewed on a quarterly basis. 

Systems that need more regular upkeep or review will need more granular tasks assigned to their maintenance. Every month, your team should hold meetings, address vulnerabilities and patching, and review industry best practices and emerging threat trends. On a weekly basis, you should run vulnerability scans and ensure security policies are being enforced. These tasks and processes should be integrated into stakeholders’ regular work so that they aren’t felt as an added burden or missed by accident. 

How to Track Your Processes

Keeping track of these processes can appear overwhelming, especially if it’s your first year after an audit. In order to maintain compliance, these processes need to be addressed in a timely way that addresses your organization’s risk, but they also need to be documented. It can be tempting to assign tasks and hope they’ll get done, but the truth is that a commitment to compliance takes a lot more time and effort. 

It’s important to define your strategy and determine how you’ll complete it in an organized manner. Beyond having a calendar of due dates, you need to be able to track which individuals in your organization are responsible for each task. You also need documentation to prove whether or not tasks have been completed. Furthermore, you need instructions on completing tasks readily available and contingent next steps if an issue is identified.  

Finding A Solution That’s Better than Binders

While the original method of tracking compliance was shelves full of binders to track and maintain processes, there is a better solution. Practical Assurance has created an automated compliance tracking software system that can help you maintain compliance with automatic reminders and project management capabilities. You can assign tasks to stakeholders, set reminders, and document completion of tasks right inside the app.

We provide this application to organizations that have some compliance experience under their belts and want to improve their tracking and maintenance systems. We also provide advisory services to organizations that are just starting their compliance programs, which includes the app as well as regular consulting on how best to implement it.

For a more in-depth look at the annual SOC 2 compliance cadence, check out our recent webinar, How to Stay SOC 2 Compliant

What is a Due Diligence Questionnaire and What Should You Do About It?

Your company just received a due diligence questionnaire (DDQ) or due diligence checklist from a potential client. You may think it’s a threat or a challenge, but it’s actually a good sign: Sending a DDQ is usually the last step a company takes before choosing to buy a service or product from a company they’ve been considering. A potential client will use the DDQ to validate that your organization is compliant with required guidelines, especially in terms of security.

There are many different types of due diligence questionnaires, and they can vary depending on what sort of service you provide. But if you are a software developer or service provider responding to an RFP, you can expect to get a DDQ from potential clients that are serious about buying from you. 

What should you do if you receive a due diligence questionnaire? First of all, don’t panic. Next up, follow our advice below.

Get Strategic by Knowing What’s On a DDQ

You can prepare for responding to DDQs even if you haven’t received one yet. The best way to put a strategy in place for responding to a due diligence list is by knowing what questions they usually include.

Virtually all DDQs require that your company can show that you follow certain key processes, such as having an information security policy and that you conduct external penetration tests every year. Other requirements include being able to show that you have implemented strong technical controls in line with industry best practices, such as:

  • Multi-factor authentication
  • Firewalls
  • Intrusion detection
  • VPNs

You’ll also need to prove that key processes such as change management, new hires, terminations, are all documented and operate as written in your policy manuals. Finally, you’ll have to prove that you have a firm understanding of the customer data that you process and store, and understand the risks involved. 

Be Ready to Show Your Work

The best way to ensure you have strong responses to DDQ questions is to show that you have a plan in place for security. Start by developing a collection of key artifacts that most DDQs look for. Some examples include:

  • Information security policy
  • Disaster recovery plan
  • Recent penetration test reports
  • Network diagram

These documents and reports will allow you to show with confidence that you meet the requirements of the due diligence checklist. 

Another form of proof you should look into is an external audit. In the early stages of a company, it’s not always necessary to have an audit completed, but you need to make sure you know what your plan is and demonstrate your roadmap. It’s perfectly ok if you’re planning an audit in 12-18 months, maybe even longer, as long as you can show that you have something in the works.

Practical Assurance can help you build your roadmap and key artifacts to set you on the right footing to land bigger customers before you’re fully read for an audit.

Approach the Questionnaire Like a Final Interview

As noted above, a DDQ is usually the last step that a company uses to verify that a vendor is doing the right thing in terms of security and compliance. If they go to the trouble of sending you a DDQ, it means they’re heavily considering your product, but want to do one final sweep for reassurance that they know exactly what risks they may be facing by using your solution, and how you will mitigate those risks for their company.

The questionnaire acts like a window into the maturity of your company. If you have weak answers to the questions it poses, your prospects will assume you’re not ready to do business with them. As with a final job interview, you need to be prepared and project confidence. How you respond can truly make or break your ability to land a deal with a new client.

If you need help preparing responses to a DDQ, or want to be prepared for larger clients who will certainly send them your way, get in touch with Practical Assurance today. 

SOC 2 Checklist – Week by Week

What does a weekly project plan and checklist look like for SOC 2 readiness? How do you prioritize practically? What are the key tasks I need to accomplish each week? 

Topics in this webinar include:

  • SOC 2 Checklist
  • 12-week readiness project plan
  • Key tasks prioritized weekly
  • Visual overview of the readiness process
  • Healthy readiness expectations

Download the webinar:

Continue reading SOC 2 Checklist – Week by Week

SOC 2 Vulnerability Management Webinar

What are the SOC 2 requirements as it relates to vulnerability management?
What do I need to watch out for when I schedule a penetration test? What are others doing to comply cost-effectively?

Topics in this webinar include:

  • The relevant SOC 2 criteria impacting vulnerability management
  • How to compliantly configure a penetration test
  • Cost-effective strategies to comply with SOC 2
  • Get inside the head of a SOC 2 auditor

Download the webinar:
Continue reading SOC 2 Vulnerability Management Webinar

A Dime of Every ICO Dollar has Already Been Stolen

Over half of all the ICOs optioned in 2017 have already failed, according to analysts, and no small portion of those failures have been due to the scandalous 10% theft rate amongst ICOs.

Of the $3.7 billion raised to fund ICOs so far, around $400 million have been stolen, mostly by very basic phishing techniques that rack up over $1.5 million per month in pilfered cryptocurrency.

While many ICOs fail simply because the companies behind them aren’t sound (or the ICOs are designed to fail as good, old-fashioned “exit scams” for nefarious founders), ICO security is emerging as a cause for concern amongst savvy cryptocurrency investors.

After all, part of the appeal of cryptocurrency is that high-grade encryption and security are integral to the technology. If simple phishing attacks can scam one in 10 customers out of your virtual currency, that’s a perfectly valid reason for investors to pass on your ICO. Even if the phishing isn’t “your fault” — some customers are going to get scammed simply because they are dumb customers, regardless of how you try to protect them — it still creates a customer service and public relations problem if your theft rate is very high.

This problem grows worse when a typical response to ICO adversity is to simply ghost on your investors and customers, in what calls a pattern of “abandoned Twitter accounts, empty Telegram groups, websites no longer hosted, and communities no longer tended.”

Investors want to know you have processes in place not just to prevent hacks, but to adequately and professionally respond when hacks occur and times are tough. Proving you have basic internal controls and professional processes in place will soon be a standard part of ICOs, just like it is for any viable investment practice.

If you want to be sure you’re taking every reasonable professional measure to make your ICO secure and sustainable, you need an ICO security audit. An audit can demonstrate to your investors (and yourself) that you won’t be part of the 10% of ICOs that get easily hacked, which will help you stay out of the 59% percent of ICOS that fail.

Get your ICO security audit today.

Is Your ICO Prepared for a “51% Attack”…?

Blockchain-based technologies are appealing because they theoretically offer decentralized transactions with no corruptible (or hackable) central management authority — but the reality of blockchain is proving somewhat different than the theory. If your ICO is built on the same basic principles as Bitcoin or Ethereum, you need to be prepared for the fallout of a possible “51% attack.”

As outlined here, a 51% attack is a case where 51% of all the miners in blockchain ecosystem are aligned with a single hashpool, or consortium of centrally controlled miners. (You could actually enact this attack with any absolute majority of miners in an ecosystem, so anything above 50%.) With a majority of miners under one controlling authority, the entire blockchain ledger is vulnerable to manipulation.

Now, blockchain was ostensibly designed to not require a central authority, but it doesn’t prevent anyone from creating one by cornering the market on miners. Recent research has shown that greater than 50% of mining on both Bitcoin and Ethereum is performed by four of fewer miners.

In a way, blockchain encourages centralization, as the more miners you control, the less variance in mining occurs — because you increase the likelihood that any transaction in the ecosystem will be routed to your miners for initial authentication. While “paying” miners in Bitcoin should theoretically encourage a diverse group of miners to all get in on the action, in reality it simply encourages the creation of bulk mining operations to get a nice stable chunk of the Bitcoin output available.

Similar unexpected externalities also seem to be encouraging the physical collocation of several blockchain mining operations. Hydro Quebec, a Canadian hydroelectric utility, ran a campaign to encourage tech companies to set up data centers in its service area, as cold weather and cheap power are ideal for inexpensive server farms. Instead of tech startups, they attracted Bitcoin miners. As a result, any major outage or disaster to befall Hydro Quebec could now have a non-trivial effect on the entire cryptocurrency ecosystem.

Most developers and investors assume that a blockchain ecosystem will be naturally decentralized and thus naturally resistant to any brute force attack or natural disaster. It turns out that the real-world implementation of blockchain – especially blockchain as it is implemented under Bitcoin – perversely encourages centralization in unexpected ways. And, because there is no Bitcoin version of the Federal Reserve to oversee these market-cornering mining operations, the risks posed by blockchain centralization are hard to assess and harder still to thwart.

That’s why every ICO needs to perform a full security and operational audit to ensure your blockchain-type technology is hardened against these unexpected brute-force attacks, and to establish protocols to respond if your blockchain is targeted for 51% majority manipulation.

If you want the market to have confidence in your ICO, you must ensure your ICO is hardened against market manipulation. Sign up for an ICO audit today.

The Security Risks of the “Junk Food ICO” Trend

One of the most dangerous aspects of an ICO is the general ignorance regarding blockchain amongst not just the public, but investors as well. The public views blockchain tokens as some sort of weird hybrid of fairy dust and gold bouillon, in that you can sprinkle blockchain on an ordinary product and suddenly it becomes immensely valuable.

For example, the Long Island Iced Tea company saw its stock value triple when it changed its name to Long Blockchain. No one knows what, if anything, Long Blockchain will actually use blockchain tech for, but the name change alone was assumed to be valuable.

By the same token (pun intended), a major Hooters franchisee is planning to convert its customer loyalty system to a blockchain rewards program, so that you can now literally measure the value of certain tokens in chicken wings and hamburgers.

The problem with these gimmicks isn’t that they are fleecing investors who still think of Bitcoin as a conventional currency. The danger is the huge risks posed by tacking on blockchain as a cash-grab, rather than as a fully secured technology. These “Junk Food ICOs” — so called not because they involve fast food companies, but because they treat blockchain as something you can just grab as quick-profit takeout food — pose real “health risks” to their parent companies.

Blockchain in general, and Bitcoin in particular, can’t be counterfeited, but can very easily be lost or stolen. And if your ICO investors assume that your tokens can be used like a conventional currency, and that they have the same protections and conveniences as modern credit cards, you’re setting yourself up for some serious customer dissatisfaction the moment the first cache of your tokens gets misplaced or social-engineered away.

Conventional currency has a safety net built in. The amount of cash in circulation is regulated by central banks, most American consumer bank accounts are insured by the FDIC, mainstream credit cards have built-in fraud protections, and American investment vehicles are regulated by the Securities and Exchange Commission. If something goes wrong, there are established protections to limit the damage and protocols for seeking restitution.

Blockchain tokens don’t have this same mature security ecosystem, and the public (nor investors nor corporations) clearly doesn’t appreciate the risks that entails. Thus, it is incumbent on you to build security into your blockchain ecosystem prior to any ICO — if only to prevent a wave of customer and partner backlash should anything go wrong.

Moreover, at some point a major consumer blockchain play is going to go bad, and the public will demand proof that any other token offering has better protections in place. The companies that invest in ICO security and compliance now will have a head start on every other blockchain firm when the public finally starts to take token security and management seriously.

Initial Coin Offerings are the Wild West of technology and investment — which means you might strike gold, or you might get robbed by bandits — but it also means that those who build their ICOs on secure foundations are best positioned to survive the chaos ahead.

If you want to ensure the security of your token technology, sign up for an ICO security and compliance audit today.

12 Critical Due Diligence Questions to Ask ICOs

Many of the most innovative companies today are choosing to raise money through token sales. Cryptocurrencies seem to be flowing more freely than investments through traditional VC route. Additionally, we’re seeing participation on a worldwide scale. It’s exciting! Who doesn’t want to earn 25x on their money? Yes, it’s fun to throw a few Ethereum at a “too good to be true” deal, but the risks are extraordinary. It’s almost certain you’ll end up losing money.

Some deals are better than others, and it’s up to you to find the good ones. Due diligence shouldn’t be reserved just traditional investors. To support the long time viability of ICOs as a funding model, it’s critical that we start being selective into which project we back. A focus on diligence and quality will raise make it nearly impossible for a scam to be successful.

Below I’ve assembled a list of key questions to consider when evaluating a token sale. If the company’s whitepaper or website doesn’t provide enough detail, I encourage you to ask the founders directly. You’ll quickly be able to determine which companies are mature enough to deserve your hard earned money.

Is the business entity properly structured? – Is there a formed business entity? What jurisdiction does the entity reside? Is it managed by a board of directors or foundation? How is the business structured?

How experienced are the founders? – Have the founders built companies or tremendous value in the past, or is this the first time? What makes the founders unique for this opportunity?

How experienced is the engineering team? – Are there industry leading experts on the team? Is key development being outsourced?

Do you have a personal connection with any on the executive team? – Do you have any close connections on LinkedIn with any key management? Is the team completely outside of your professional network?

How does the company approach risk management? – Is the company simply reactive to business and information security risks? Have contingencies been planned in detail? Are all attack vectors documented and managed?  Does the company have a culture that emphasizes security over convenience?

What are the internal fraud prevention controls? – Have segregation of duties been setup around key financial processes? How are funds moved and managed on a day by day basis? Does the company have a documented code of ethics?

How are key internal processes managed? – Is there an information security policy? What is the business continuity plan? Is there any incident response plan?  How is customer support managed?

Have you audited your smart contracts? – Have smart contracts and other code been audited by a third party? What are the internal processes for code quality and static analysis?

How are information security vulnerabilities managed – Is there internal vulnerability scanning? Are external endpoints pentested by a third party?  Have all medium and higher identified vulnerabilities been remediated?

How mature is the system architecture? – Are key components properly segregated to minimize risk? Can the system architecture be clearly described in a diagram? Has external exposure been minimized?

Is there a communication plan? — How are you notified if there are problems in the system or offering?  What are the scenarios in which token buyers would not be contacted?  What is the breach notification policy?

How transparent is the company? — How much information was provided up front? How did the company respond with regards to their weaknesses?

This is just a small sample of the questions you should be asking when evaluating an ICO.  If you’re planning an ICO, giving this type of information up front will help buyers evaluate the risks involved with yours company.  Building trust does not come easy.

As a token buyer, ICOs are a great way to participate in blockchain technology.  Asking the right questions will help you minimize risk.

Security for ICOs and Token Sales

Last week, we introduced the ICO Information Security Framework (IISF) to assist companies in the process of a token sale by improving information security practices.

ICOs and token sales have recently attracted a lot of attention from hackers/fraudsters due such large values at stake. If you’re considering a token sale, it’s important that you protect your own environment and communication channels to ensure that funds are not stolen. The IISF was created to so that you can have high assurance that your company’s internal processes are in-line with information security best practices and reduce the risk of a compromise.

Additionally, it’s extremely important to build a strong information security foundation so that you can gain a high level of trust with investors and/or potential token buyers. ICOs are usually opaque at best, we help companies prepare their security practices and communicate trust to all parties involved.

The ISO Information Security Framework™ has been developed with the core purpose of enabling companies that are planning an ICO or token sale to build a strong foundation of information security and compliance. This is important to increase investor and customer confidence and improve the maturity of the business processes under control by the company. The IISF can serve as a due diligence function for those wishing to buy tokens.

If you’re considering an ICO or token sale and are looking for guidance on how to improve your information security practices, please don’t hesitate to reach out.

OSSEC & ELK Stack Integration

OSSEC is the leading open-source host-based intrusion detection system (HIDS) software on the market today. OSSEC performs log analysis, integrity checking, Windows registry monitoring, and much more. It is setup in a server client configuration that can be installed and setup from simple scripts within minutes.

OSSEC offers an open-source web user interface (Web UI) that is very basic and not very customizable. To change this, companies started to integrate with Elasticsearch, Logstash, and Kibana (ELK Stack) giving users more freedom to customize dashboards and find the data they needed faster. This integration has been lead by the open-source project from the team over at Wazuh. They have made a customized version of OSSEC that is configured to automatically integrate with the ELK Stack which also includes some custom OSSEC rules that helps you monitor your systems in regards to PCI and CIS compliance.

This post will guide you through the process of installing OSSEC Server and guide you how to integrate OSSEC with with the ELK Stack on Ubuntu 14.04 Server. We will also describe how to import the custom PCI and CIS Wazuh dashboards and custom rules.

OSSEC Server Installation

Copy scripts folder to server using a secure copy command

scp -r {{PATH_TO_TEMP_FOLDER}} {{ubuntu_user}}@{{Server_IP}}:/home/{{ubuntu_user}}/

SSH into your Ubuntu 14.04 Server and go to the OSSEC_ELK_Temp directory in your home directory. Run the bash script.

sudo bash

Answer Y to confirm the installation from apt-get and then enter your preferred language.


On the next screen, press ENTER to continue and then type “server” when the installation asks what kind of installation do you want.


For the proceeding questions, use the following answers:

  • Question 2 choose the default option [var/ossec]
  • Question 3.1, enter your email address and confirm the SMTP server.
  • Question 3.2 choose the default option [y]
  • Question 3.3 choose the default option [y]
  • Question 3.4 choose the default option [y] for both questions
  • Question 3.4 Part 3 choose the default option [n]
  • Question 3.5 choose the default option [y]

After answering all the questions, press ENTER to run the installation and your final result should state “Configuration finished properly.”


Press ENTER and the bash script will start OSSEC. A result of “Completed.” should be shown


Next you will want to add an agent to get some logs flowing into OSSEC. Press A to add an agent and then fill out the Name of the new agent, the IP, and the agent id. Confirm adding the new agent by entering Y.

NOTE: The bash script automatically opens the agent manager but to add more agents in the future run /var/ossec/bin/manage_agents


OSSEC Agent Installation

Open the OSSEC Agent Manager console if it is not open already

sudo /var/ossec/bin/manage_agents

Enter “E” stating you want to extract an agent key and then enter the agent ID that you want to extract. Highlight and copy the key to be used after the agent has been installed.


Copy Scripts folder to the agent server using a secure copy command

scp -r {{PATH_TO_TEMP_FOLDER}} {{ubuntu_user}}@{{Server_IP}}:/home/{{ubuntu_user}}/

On the Agent Server, change into the OSSEC_ELK_TEMP folder and then run the bash script to install the OSSEC Agent

sudo bash

A configuration window will appear and enter the IP Address of your OSSEC Server


In the Agent Manager, enter “I” stating you want to add an agent key, and then paste the key into the agent manager. Press enter, and confirm the entry by entering “y”.


ELK Stack Architecture

Elasticsearch, Logstash, and Kibana can be configured in a multitude of ways. This guide will be using the single host configuration where all components of the ELK Stack including OSSEC is installed on the same virtual machine. The ELK Stack can be distributed across multiple hosts and this configuration can be explained more in detail here in the Wazuh project documentation.

ELK Stack Prerequisites

Elasticsearch, Logstash, and Kibana require the Java 8 JRE to be installed. To install this, on the OSSEC Server machine go to the scripts folder that you copied over earlier and run the bash script to install Java 8 JRE.

sudo bash

Logstash Installation

To install Logstash, on the OSSEC Server machine go to the scripts folder that you copied earlier and run the bash script.

sudo bash

Install Elasticsearch

To install Elasticsearch, on the OSSEC Server machine go to the scripts folder that you copied earlier and run the bash script.

sudo bash

The script will automatically open up the elasticsearch.yml file, in the file set the equal to “ossec”, and the equal to “ossec_node1”


At the end of the elasticsearch.yml file, add the following lines shown in the image below to the end of the file. Then save the file and exit out of it.


Next, the script will open the limits.conf file. Add the following lines shown in the image below to the end of the file. Then save the file and exit out of it.


Next, the script will open the default/elasticsearch file. In this file set the ES_HEAP_SIZE equal to half the amount of RAM on the system.


In the same file, uncomment the following lines shown in the image below. Then save the file and exit out of it.


Kibana Installation

To install Kibana, on the OSSEC Server machine go to the scripts folder that you copied earlier and run the bash script.

sudo bash

Once the script has completed, in your web browser on your local machine navigate to http://{{OSSEC/ELK Host IP}}:5601. This should open up the Kibana web interface.

Next you will need to import the OSSEC index pattern by typing “ossec-*” into the textbox and then click create.


In the navigation select “Discover”. This shows all of the recent OSSEC alerts. 


Wazuh Custom Dashboards

By default, the custom Wazuh dashboards are not imported into Kibana. To import them, navigate to this link and download the JSON file to your local machine.

In Kibana, go to settings, objects, and then click on import and select the JSON file you just downloaded.


3 dashboard should appear in the list. Click on the eye icon next to the OSSEC Alerts Dashboard to open the OSSEC Alerts Dashboard.


Wazuh Custom Rules

To import Wazuh’s custom OSSEC rules, on the OSSEC/ELK server, navigate to the scripts folder that you copied earlier and run the bash script.

sudo bash

When crontab opens, add this line to the bottom of your crontab file to update the Wazuh rules on a weekly basis, then save and exit the crontab file. 

@weekly root cd /var/ossec/update/ruleset && ./ -s


In the root directory of your user’s home folder on the OSSEC/ELK server, run the following commands to remove the temporary files.

sudo rm -rf ossec_tmp/
sudo rm -rf OSSEC_ELK_TEMP/


Completing this guide and getting OSSEC and the ELK Stack running is just the start of what can be accomplished. Custom Kibana dashboards can be created that allows you to monitor the alerts that are most important to your company. OSSEC can also be customized allowing you to create custom rules and rulesets that could be integrated into your custom dashboards. As more agents are added to the OSSEC server and more user start accessing Kibana, using the distributed architecture would become more important allowing the system to grow and expand.

We would like to thank the Wazuh project for all the hard work and dedication they have put in making the integration of OSSEC and the ELK Stack quick and simple. If you would like more information about the Wazuh Project, the ELK Stack, or OSSEC, view the links below.

Wazuh Project

ELK Stack