Oct
05
2020
--

Strike Graph raises $3.9M to help automate security audits

Compliance automation isn’t exactly the most exciting topic, but security audits are big business and companies that aim to get a SOC 2, ISO 207001 or FedRamp certification can often spend six figures to get through the process with the help of an auditing service. Seattle-based Strike Graph, which is launching today and announcing a $3.9 million seed funding round, wants to automate as much of this process as possible.

The company’s funding round was led by Madrona Venture Group, with participation from Amplify.LA, Revolution’s Rise of the Rest Seed Fund and Green D Ventures.

Strike Graph co-founder and CEO Justin Beals tells me that the idea for the company came to him during his time as CTO at machine learning startup Koru (which had a bit of an odd exit last year). To get enterprise adoption for that service, the company had to get a SOC 2 security certification. “It was a real challenge, especially for a small company. In talking to my colleagues, I just recognized how much of a challenge it was across the board. And so when it was time for the next startup, I was just really curious,” he told me.

Image Credits: Strike Graph

Together with his co-founder Brian Bero, he incubated the idea at Madrona Venture Labs, where he spent some time as Entrepreneur in Residence after Koru.

Beals argues that today’s process tends to be slow, inefficient and expensive. The idea behind Strike Graph, unsurprisingly, is to remove as many of these inefficiencies as is currently possible. The company itself, it is worth noting, doesn’t provide the actual audit service. Businesses will still need to hire an auditing service for that. But Beals also argues that the bulk of what companies are paying for today is pre-audit preparation.

“We do all that preparation work and preparing you and then, after your first audit, you have to go and renew every year. So there’s an important maintenance of that information.”

Image Credits: Strike Graph

When customers come to Strike Graph, they fill out a risk assessment. The company takes that and can then provide them with controls for how to improve their security posture — both to pass the audit and to secure their data. Beals also noted that soon, Strike Graph will be able to help businesses automate the collection of evidence for the audit (say your encryption settings) and can pull that in regularly. Certifications like SOC 2, after all, require companies to have ongoing security practices in place and get re-audited every 12 months. Automated evidence collection will launch in early 2021, once the team has built out the first set of its integrations to collect that data.

That’s also where the company, which mostly targets mid-size businesses, plans to spend a lot of its new funding. In addition, the company plans to focus on its marketing efforts, mostly around content marketing and educating its potential customers.

“Every company, big or small, that sells a software solution must address a broad set of compliance requirements in regards to security and privacy. Obtaining the certifications can be a burdensome, opaque and expensive process. Strike Graph is applying intelligent technology to this problem — they help the company identify the appropriate risks, enable the audit to run smoothly and then automate the compliance and testing going forward,” said Hope Cochran, managing director at Madrona Venture Group. “These audits were a necessary pain when I was a CFO, and Strike Graph’s elegant solution brings together teams across the company to move the business forward faster.”

Dec
28
2012
--

Auditing login attempts in MySQL

This is a recurrent question made by our MySQL Support customers:

How can I audit the login attempts in MySQL?

Logging all the attempts or just the failed ones is a very important task on some scenarios. Unfortunately there are not too many audit capabilities in MySQL Community so the first option to audit MySQL’s authentication process is to get all the information we need from logs.

General Query Log

The first option is the General Query Log. Let’s see an example:

Enable the log:

general_log_file        = /var/log/mysql/mysql.log
general_log             = 1

User correctly authenticated:

121227  8:31:49	   38 Connect	root@localhost on 
		   38 Query	select @@version_comment limit 1

User not correctly authenticated:

121227  8:32:18	   39 Connect	root@localhost on 
		   39 Connect	Access denied for user 'root'@'localhost' (using password: YES)

The problem of the General Query Log is that it will log everything so it can cause performance degradation and you will have to deal with very large files on high loaded servers. general_log variable is dynamic so a solution could be enabling and disabling the log just when it’s needed.

Error log

If you only care about failed attempts to login then there is another different and less problematic approach. From 5.5 it’s possible to log access denied messages to the error log.

We just need to enable log_warnings with a value greater than 1:

log_warnings = 2

Then check the error log:

121227  8:44:21 [Warning] Access denied for user 'root'@'localhost' (using password: YES)

User Statistics

If you are using Percona Server then there is a third option to get information about our users, the User Statistics. As with the previous options we can get the number of connections and failed connections made by a particular user but not the date and time of those attempts. Besides that information we can get other statistics that can be very useful if MySQL is running on a multi-tenant environment or we need to control how resources are used.

Let’s seen an example, first we enable User Statistics in my.cnf:

5.5

userstat = 1

5.1

userstat_running = 1

Then we get the information about a particular user:

mysql> select * from user_statistics where user='root'\G
*************************** 1. row ***************************
                  USER: root
     TOTAL_CONNECTIONS: 25
CONCURRENT_CONNECTIONS: 0
        CONNECTED_TIME: 464
             BUSY_TIME: 96
              CPU_TIME: 19
        BYTES_RECEIVED: 62869617
            BYTES_SENT: 14520
  BINLOG_BYTES_WRITTEN: 0
          ROWS_FETCHED: 783051
          ROWS_UPDATED: 1017714
       TABLE_ROWS_READ: 1484751
       SELECT_COMMANDS: 14
       UPDATE_COMMANDS: 103
        OTHER_COMMANDS: 3556
   COMMIT_TRANSACTIONS: 0
 ROLLBACK_TRANSACTIONS: 0
    DENIED_CONNECTIONS: 2
      LOST_CONNECTIONS: 16
         ACCESS_DENIED: 0
         EMPTY_QUERIES: 0
 TOTAL_SSL_CONNECTIONS: 0

Here we can see that root has done 25 total connections. Two denied connections (bad password) and 16 lost connections (not closed properly). Apart from that information we get the connection time, bytes received and sent, rows accessed, commands executed and so on. Very valuable information.

It is important to mention that these tables are stored in INFORMATION_SCHEMA and that means that after a mysqld restart all the information will be lost. So if you really need that information you should copy it to another table or export to a csv for further analysis.

Conclusion

We don’t have too many audit capabilities in MySQL Community so logging all events and then filter them with custom-made scripts is the best solution we have nowadays. If you are using Percona Server you can get more detailed information about what a particular user is doing. All options can be combined to meet your needs.

The post Auditing login attempts in MySQL appeared first on MySQL Performance Blog.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com