May
23
2018
--

Okta introduces ‘Sign in with Okta’ service

Consider that there are millions of Okta users out there using the service to sign into their company applications with a single set of credentials. Yet getting customers to work together using Okta authentication was an enormous task for developers. Okta wanted to simplify it, so they created a service they are calling it ‘Sign in with Okta.’

The new API allows developers to add a few lines code and give Okta customers the ability to sign into one another’s websites in a similar way that OAuth allows you to use your Google or Facebook credentials to sign onto consumer sites.

Frederic Kerrest, COO and co-founder at Okta, says the ‘Sign in with Okta’ uses an extension of OAuth called OpenID Connect, which his company has been supporting since 2016. He says the new service gives customers the ability to expand the use of their Okta credentials beyond their own set of internal applications to sign into customer and partner sites. This extends the Okta functionality and brand and helps to make it a kind of standard way of logging in (or that’s the hope).

When developers add this functionality, the user sees a “Sign in with Okta” button on the website or service they are accessing. They can then use their Okta login to get into these sites under whatever rules the site owner has defined.

Site with ‘Sign in with Okta’ button. Photo: Okta

While Okta has provided APIs for developers prior to today, they didn’t provide a package like this that simplifies the process. This forced developers to use the SAML standard to make it work. While there’s nothing wrong with this approach, it can be time-consuming and put a lot of burden on developers to write software and connectors, while updating and maintaining them, Kerrest explained. This removes all of that complexity from the process.

This means that when two businesses are on Okta, they can trust one another because they do business together, and instead of setting up the SAML connection, a process that could take days, they can do it an hour with the Okta API tool, according to Kerrest.

“[Sign in with Okta] is a much easier way for customers or partners to seamlessly integrate into our environment. They could do it before, but we are ‘widgetizing’ it now,” he said.

May
15
2018
--

Auth0 snags $55M Series D, seeks international expansion

Auth0, a startup based in Seattle, has been helping developers with a set of APIs to build authentication into their applications for the last five years. It’s raised a fair bit of money along the way to help extend that mission, and today the company announced a $55 million Series D.

This round was led by led by Sapphire Ventures with help from World Innovation Lab, and existing investors Bessemer Venture Partners, Trinity Ventures, Meritech Capital and K9 Ventures. Today’s investment brings the total raised to $110 million. The company did not want to share its valuation.

CEO Eugenio Pace said the investment should help them expand further internationally. In fact, one of the investors, World Innovation Lab, is based in Japan and should help with their presence there. “Japan is an important market for us and they should help explain to us how the market works there,” he said.

The company offers an easy way for developers to build in authentication services into their applications, also known as Identification as a Service (IDaaS). It’s a lot like Stripe for payments or Twilio for messaging. Instead of building the authentication layer from scratch, they simply add a few lines of code and can take advantage of the services available on the Auth0 platform.

That platform includes a range of service such as single-sign on, two-factor identification, passwordless log-on and breached password detection.

They have a free tier, which doesn’t even require a credit card, and pay tiers based on the types of users — regular versus enterprise — along with the number of users. They also charge based on machine-to-machine authentication. Pace reports they have 3500 paying customers and tens of thousands of users on the free tier.

All of that has added up to a pretty decent business. While Pace would not share specific numbers, he did indicate the company doubled its revenue last year and expected to do so again this year.

With a cadence of getting funding every year for the last three years, Pace says this round may mark the end of that fundraising cycle for a time. He wasn’t ready to commit to the idea of an IPO, saying that is likely a couple of years away, but he says the company is close to profitability.

With the new influx of money, the company does plan to expand its workforce as moves into markets across the world . They currently have 300 employees, but within a year he expects to be between 400 and 450 worldwide.

The company’s last round was a $30 million Series C last June led by Meritech Capital Partners.

May
14
2018
--

Xage introduces fingerprinting to protect industrial IoT devices

As old-school industries like oil and gas increasingly network entities like oil platforms, they become more vulnerable to hacking attacks that were impossible when they were stand-alone. That requires a new approach to security and Xage (pronounced Zage), a security startup that launched last year thinks it has the answer with a concept called ‘fingerprinting’ combined with the blockchain.

“Each individual fingerprint tries to reflect as much information as possible about a device or controller,” Duncan Greatwood, Xage’s CEO explained. They do this by storing configuration data from each device and controller on the network. That includes the hardware type, the software that’s installed on it, the CPU ID, the storage ID and so forth.

If someone were to try to inject malware into one of these controllers, the fingerprint identification would notice a change and shut it down until human technicians could figure out if it’s a legitimate change or not.

Whither blockchain?

You may be wondering where the blockchain comes into this, but imagine a honey pot of these fingerprints were stored in a conventional database. If that database were compromised, it would mean hackers could have access to a company’s entire store of fingerprints, completely neutering that idea. That’s where the blockchain comes in.

Greatwood says it serves multiple purposes to prevent such a scenario from happening. For starters, it takes away that centralized honey pot. It also provides a means of authentication making it impossible to insert a fake fingerprint without explicit permission to do so.

But he says that Xage takes one more precaution unrelated to the blockchain to allow for legitimate updates to the controller. “We have a digital replica (twin) of the system we keep in the cloud, so if someone is changing the software or plans to change it on a device or controller, we will pre-calculate what the new fingerprint will be before we update the controller,” he said. That will allow them to understand when there is a sanctioned update happening and not an external threat agent trying to mimic one.

Checks and balances

In this way they check the validity of every fingerprint and have checks and balances every step of the way. If the updated fingerprint matches the cloud replica, they can be reasonably assured that it’s authentic. If it doesn’t, he says they assume the fingerprint might have been hacked and shut it down for further investigation by the customer.

While this sounds like a complex way of protecting this infrastructure, Greatwood points out that these devices and controllers tend to be fairly simple in terms of their configuration, not like the complexities involved in managing security on a network of workstations with many possible access points for hackers.

The irony here is that these companies are networking their devices to simplify maintenance, but in doing so they have created a new set of issues. “It’s a very interesting problem. They are adopting IoT, so they don’t have to do [so many] truck rolls. They want that network capability, but then the risk of hacking is greater because it only takes one hack to get access to thousands of controllers,” he explained.

In case you are thinking they may be overstating the actual problem of oil rigs and other industrial targets getting hacked, a Department of Homeland Security report released in March suggests that the energy sector has been an area of interest for nation-state hackers in recent years.

Apr
30
2018
--

Keep Sensitive Data Secure in a Replication Setup

Keep sensitive data secure

Keep sensitive data secureThis blog post describes how to keep sensitive data secure on slave servers in a MySQL async replication setup.

Almost every web application has a sensitive data: passwords, SNN, credit cards, emails, etc. Splitting the database to secure and “public” parts allows for restricting user and application parts access to sensitive data.

Field encryption

This is based on MySQL encryption functions or on client-side encryption when the authorized user knows a secret, but encrypted data is distributed to all slaves.

  • If possible, use hashes with a big enough salt, and do not store real sensitive data in the database. A good example is passwords. An end-user sends the login and password, application/SQL code calculates the hash with a salt value unique for each end-user and compares the hash with the value stored in the database. Even if the attacker gets the hashes, it’s still hard or even impossible to extract real passwords for all users. Make sure that you are using a good random number generator for the salt, application-side secret, and a good hash function (not MD5).
  • Encryption is not suitable if you are going to provide public access to your database (via slave dumps in sql/csv/xml/json format).
  • Encryption is a complex topic. Check here for a good blog post explaining hashing usage, and try to find a security consultant if you are inventing some “new” method of storing and encrypting data.

Field encryption example

I’m using a single server setup, because the most important part of data separation should be done on the application side. The secure part of the application has a secret passphrase. For example, you can place the code working with authentication, full profile and payments on a separate server and use a dedicated MySQL account.

create database encrypted;
use encrypted;
create table t(c1 int, c2 varchar(255), rnd_pad varbinary(16), primary key(c1));
SET block_encryption_mode = 'aes-256-cbc';
SET @key_str = SHA2('My secret passphrase',512);
SET @init_vector = RANDOM_BYTES(16);
insert into t (c1,c2, rnd_pad) values (1, AES_ENCRYPT('Secret', @key_str, @init_vector), @init_vector);
-- decrypt data
select c1, AES_DECRYPT(c2,@key_str, rnd_pad) from t;

Summary

  • GOOD: Master and slave servers have exactly the same data and no problems with replication.
  • GOOD: Even if two different end-users have exactly the same password, the stored values are different due to random bytes in the init vector for AES encryption.
  • GOOD: Both the encryption and random number generation uses an external library (openssl).
  • CONF: It’s important to have binlog_format=ROW to avoid sending the secret to slave servers.
  • CONF: Do not allow end-users to change data without changing the init_vector, especially for small strings without random padding. Each update should cause init_vector re-generation.
  • BAD: Encrypted data is still sent to slave servers. If the encryption algorithm or protocol is broken, it is possible to get access to data from an insecure part of the application.
  • BAD: The described protocol still could be insecure.

Replication filters

There are two types of replication filters: a master-side with binlog-*db and a slave-side with replicate-*.

Both could cause replication breakage. Replication filters were created for STATEMENT-based replication and are problematic with modern binlog_format=ROW + gtid_mode=on setup. You can find several cases related to database-level slave-side filters in this blog post. If you still need slave-side filtering, use per-table replicate-wild-*-table options.

Master-side

Even if binary logging is disabled for a specific database, the statement still could be stored in the binary log if it’s a DDL statement, or if the binlog_format is STATEMENT or MIXED and default database is not used by the statement. For details, see the reference manual for the binlog-do-db option. In order to avoid replication issues, you should use ROW-based replication and run SET SESSION sql_log_bin=0; before each DDL statement is executed against the ignored database. It’s not a good idea to use binlog-do-db, because you are losing control of what should be replicated.

Why is binary log filtering useful? Changing the sql_log_bin variable is prohibited inside transactions. The sql_log_bin is DANGEROUS, please do not use it instead of binlog-ignore-db in production on the application side. If you need it for database administration, make sure that you are always typing the “session” word before sql_log_bin. This makes problematic consistent updates of multiple entities inside database.

We still should have the ability to hide just one column from the table. But if we are ignoring the database, we should provide a method of reading non-secure data on slaves / by restricted MySQL accounts. This is possible with triggers and views:

create database test;
set session sql_log_bin=0;
create table test.t(c1 int, c2 int, primary key(c1));
alter table test.t add primary key(c1);
set session sql_log_bin=1;
create database test_insecure;
create table test_insecure.t(c1 int, c2 int default NULL, primary key(c1));
use test
delimiter //
create trigger t_aft_ins
after insert
 on test.t FOR EACH ROW
BEGIN
  INSERT test_insecure.t (c1) values (NEW.c1);
END //
create trigger t_aft_upd
after update
 on test.t FOR EACH ROW
BEGIN
  UPDATE test_insecure.t SET c1 = NEW.c1 WHERE c1 = OLD.c1;
END //
create trigger t_aft_del
after delete
 on test.t FOR EACH ROW
BEGIN
  DELETE FROM test_insecure.t WHERE c1 = OLD.c1;
END //
delimiter ;
-- just on slave:
create database test;
create view test.t as select * from test_insecure.t;
-- typical usage
INSERT INTO test.t values(1,1234);
SELECT * from test.t; -- works on both master and slave, c2 field will have NULL value on slave.

Summary

  • BAD: The data is not the same on the master and slaves. It potentially breaks replication. It’s not possible to use a slave’s backup to restore the master or promote the slave as a new master.
  • BAD: Triggers could reduce DML statement performance.
  • GOOD: The sensitive data is not sent to slaves at all (and not written to binary log).
  • GOOD: It works with GTID
  • GOOD: It requires no application changes (or almost no application changes).
  • GOOD: binlog-ignore-db allows us to not use the dangerous sql_log_bin variable after initial table creation.

The post Keep Sensitive Data Secure in a Replication Setup appeared first on Percona Database Performance Blog.

Apr
23
2018
--

Percona Live 2018 Featured Talk: Data Integrity at Scale with Alexis Guajardo

Alexis Google Percona Live 2018

Percona Live 2018 Featured TalkWelcome to another interview blog for the rapidly-approaching Percona Live 2018. Each post in this series highlights a Percona Live 2018 featured talk at the conference and gives a short preview of what attendees can expect to learn from the presenter.

This blog post highlights Alexis Guajardo, Senior Software Engineer at Google.com. His session talk is titled Data Integrity at Scale. Keeping data safe is the top responsibility of anyone running a database. In this session, he dives into Cloud SQL’s storage architecture to demonstrate how they check data down to the disk level:

Percona: Who are you, and how did you get into databases? What was your path to your current responsibilities?

Alexis: I am a Software Engineer on the Cloud SQL team with Google Cloud. I got into databases by using FileMaker. However, the world of database technology has changed many times over since then.

Percona: Your session is titled “Data Integrity at Scale”. Has the importance of data integrity increased over time? Why?

Alexis Google Percona Live 2018Alexis: Data integrity has always been vital to databases and data in general. The most common method is using checksum validation to ensure data integrity. The challenge that we faced at Cloud SQL on Google Cloud was how to do this for two very popular open source database solutions, and how to do it at scale. The store for MySQL was a bit more straightforward, because of innochecksum.  PostgreSQL required our team to create a utility, which is open sourced. The complicated aspect of data corruption is that sometimes it is dormant and discovered at a most inopportune time. What we have instituted are frequent checks for corruption of the entire data set, so if there is a software bug or other issue, we can mitigate it as soon as possible.

Percona: How does scaling affect the ability to maintain data integrity?

AlexisThere is a benefit to working on a team that provides a public cloud. Since Google Cloud is not bounded by most restrictions that an individual or company would be, we can allocate resources to do data integrity verifications without restriction. If I were to implement a similar system at a smaller company, most likely there would be cost and resource restrictions. However, data integrity is a feature that Google Cloud provides.

Percona: What are three things a DBA should know about ensuring data integrity?

Alexis: I think that the three things can be simplified down to three words: verify your backups.

Even if someone does not use Cloud SQL, it is vital to take backups, maintain them and verify them. Having terabytes of backups, but without verification, leaves open the possibility that a software bug or hardware issue somehow corrupted a backup.

Percona: Why should people attend your talk? What do you hope people will take away from it? 

Alexis: I would say the main reason to attend my talk is to discover more about Cloud SQL. As a DBA or developer, having a managed database as a service solution takes away a lot of the minutia. But there are still the tasks of improving queries and creating applications.  However, having reliable and verified backups is vital. With the addition of high availability and the ability to scale up easily, Cloud SQL’s managed database solution makes life much easier.

Percona: What are you looking forward to at Percona Live (besides your talk)?

Alexis: The many talks about Vitesse look very interesting. It is also an open source Google technology, and to see its adoption by many companies and how they have benefited from its use will be interesting.

Want to find out more about this Percona Live 2018 featured talk, and data integrity at scale? Register for Percona Live 2018, and see Alexis session talk Data Integrity at Scale. Register now to get the best price! Use the discount code SeeMeSpeakPL18 for 10% off.

Percona Live Open Source Database Conference 2018 is the premier open source event for the data performance ecosystem. It is the place to be for the open source community. Attendees include DBAs, sysadmins, developers, architects, CTOs, CEOs, and vendors from around the world.

The Percona Live Open Source Database Conference will be April 23-25, 2018 at the Hyatt Regency Santa Clara & The Santa Clara Convention Center.

The post Percona Live 2018 Featured Talk: Data Integrity at Scale with Alexis Guajardo appeared first on Percona Database Performance Blog.

Apr
21
2018
--

In the NYC enterprise startup scene, security is job one

While most people probably would not think of New York as a hotbed for enterprise startups of any kind, it is actually quite active. When you stop to consider that the world’s biggest banks and financial services companies are located there, it would certainly make sense for security startups to concentrate on such a huge potential market — and it turns out, that’s the case.

According to Crunchbase, there are dozens of security startups based in the city with everything from biometrics and messaging security to identity, security scoring and graph-based analysis tools. Some established companies like Symphony, which was originally launched in the city (although it is now on the west coast), has raised almost $300 million. It was actually formed by a consortium of the world’s biggest financial services companies back in 2014 to create a secure unified messaging platform.

There is a reason such a broad-based ecosystem is based in a single place. The companies who want to discuss these kinds of solutions aren’t based in Silicon Valley. This isn’t typically a case of startups selling to other startups. It’s startups who have been established in New York because that’s where their primary customers are most likely to be.

In this article, we are looking at a few promising early-stage security startups based in Manhattan

Hypr: Decentralizing identity

Hypr is looking at decentralizing identity with the goal of making it much more difficult to steal credentials. As company co-founder and CEO George Avetisov puts it, the idea is to get rid of that credentials honeypot sitting on the servers at most large organizations, and moving the identity processing to the device.

Hypr lets organizations remove stored credentials from the logon process. Photo: Hypr

“The goal of these companies in moving to decentralized authentication is to isolate account breaches to one person,” Avetisov explained. When you get rid of that centralized store, and move identity to the devices, you no longer have to worry about an Equifax scenario because the only thing hackers can get is the credentials on a single device — and that’s not typically worth the time and effort.

At its core, Hypr is an SDK. Developers can tap into the technology in their mobile app or website to force the authorization to the device. This could be using the fingerprint sensor on a phone or a security key like a Yubikey. Secondary authentication could include taking a picture. Over time, customers can delete the centralized storage as they shift to the Hypr method.

The company has raised $15 million and has 35 employees based in New York City.

Uplevel Security: Making connections with graph data

Uplevel’s founder Liz Maida began her career at Akamai where she learned about the value of large data sets and correlating that data to events to help customers understand what was going on behind the scenes. She took those lessons with her when she launched Uplevel Security in 2014. She had a vision of using a graph database to help analysts with differing skill sets understand the underlying connections between events.

“Let’s build a system that allows for correlation between machine intelligence and human intelligence,” she said. If the analyst agrees or disagrees, that information gets fed back into the graph, and the system learns over time the security events that most concern a given organization.

“What is exciting about [our approach] is you get a new alert and build a mini graph, then merge that into the historical data, and based on the network topology, you can start to decide if it’s malicious or not,” she said.

Photo: Uplevel

The company hopes that by providing a graphical view of the security data, it can help all levels of security analysts figure out the nature of the problem, select a proper course of action, and further build the understanding and connections for future similar events.

Maida said they took their time creating all aspects of the product, making the front end attractive, the underlying graph database and machine learning algorithms as useful as possible and allowing companies to get up and running quickly. Making it “self serve” was a priority, partly because they wanted customers digging in quickly and partly with only 10 people, they didn’t have the staff to do a lot of hand holding.

Security Scorecard: Offering a way to measure security

The founders of Security Scorecard met while working at the NYC ecommerce site, Gilt. For a time ecommerce and adtech ruled the startup scene in New York, but in recent times enterprise startups have really started to come on. Part of the reason for that is many people started at these foundational startups and when they started their own companies, they were looking to solve the kinds of enterprise problems they had encountered along the way. In the case of Security Scorecard, it was how could a CISO reasonably measure how secure a company they were buying services from was.

Photo: Security Scorecard

“Companies were doing business with third-party partners. If one of those companies gets hacked, you lose. How do you vett the security of companies you do business with” company co-founder and CEO Aleksandr Yampolskiy asked when they were forming the company.

They created a scoring system based on publicly available information, which wouldn’t require the companies being evaluated to participate. Armed with this data, they could apply a letter grade from A-F. As a former CISO at Gilt, it was certainly a paint point he felt personally. They knew some companies did undertake serious vetting, but it was usually via a questionnaire.

Security Scorecard was offering a way to capture security signals in an automated way and see at a glance just how well their vendors were doing. It doesn’t stop with the simple letter grade though, allowing you to dig into the company’s strengths and weaknesses and see how they compare to other companies in their peer groups and how they have performed over time.

It also gives customers the ability to see how they compare to peers in their own industry and use the number to brag about their security position or conversely, they could use it to ask for more budget to improve it.

The company launched in 2013 and has raised over $62 million, according to Crunchbase. Today, they have 130 employees and 400 enterprise customers.

If you’re an enterprise security startup, you need to be where the biggest companies in the world do business. That’s in New York City, and that’s precisely why these three companies, and dozens of others have chosen to call it home.

Apr
18
2018
--

Stripe debuts Radar anti-fraud AI tools for big businesses, says it has halted $4B in fraud to date

Cybersecurity continues to be a growing focus and problem in the digital world, and now Stripe is launching a new paid product that it hopes will help its customers better battle one of the bigger side-effects of data breaches: online payment fraud. Today, Stripe is announcing Radar for Fraud Teams, an expansion of its free AI-based Radar service that runs alongside Stripe’s core payments API to help identify and block fraudulent transactions.

And there are further efforts that Stripe is planning in coming months. Michael Manapat, Stripe’s engineering manager for Radar and machine learning, said the company is going to soon launch a private beta of a “dynamic authentication” that will bring in two-factor authentication. This is on top of Stripe’s first forays into using biometric factors in payments, made via partners like Apple and Google. With these and others, fingerprints and other physical attributes have become increasingly popular ways to identify mobile and other users.

The initial iteration of Radar launched in October 2016, and since then, Manapat tells me that it has prevented $4 billion in fraud for its “hundreds of thousands” of customers.

Considering the wider scope of how much e-commerce is affected by fraud — one study estimates $57.8 billion in e-commerce fraud across eight major verticals in a one-year period between 2016 and 2017 — this is a decent dent, but there is a lot more work to be done. And Stripe’s position of knowing four out of every five payment card numbers globally (on account of the ubiquity of its payments API) gives it a strong position to be able to tackle it.

The new paid product comes alongside an update to the core, free product that Stripe is dubbing Radar 2.0, which Stripe claims will have more advanced machine learning built into it and can therefore up its fraud detection by some 25 percent over the previous version.

New features for the whole product (free and paid) will include being able to detect when a proxy VPN is being used (which fraudsters might use to appear like they are in one country when they are actually in another) and ingesting billions of data points to train its model, which is now being updated on a daily basis automatically — itself an improvement on the slower and more manual system that Manapat said Stripe has been using for the past couple of years.

Meanwhile, the paid product is an interesting development.

At the time of the original launch, Stripe co-founder John Collison hinted that the company would be considering a paid product down the line. Stripe has said multiple times that it’s in no rush to go public — and statement that a spokesperson reiterated this week — but it’s notable that a paid tier is a sign of how Stripe is slowly building up more monetization and revenue generation.

Stripe is valued at around $9.2 billion as of its last big round in 2016. Most recently, it raised $150 million back in that November 2016 round. A $44 million from March of this year, noted in Pitchbook, was actually related to issuing stock related to its quiet acquisition of point-of-sale payments startup Index in that month — incidentally another interesting move for Stripe to expand its position and placement in the payments ecosystem. Stripe has raised around $450 million in total.

The Teams product, aimed at businesses that are big enough to have dedicated fraud detection staff, will be priced at an additional $0.02 per transaction, on top of Stripe’s basic transaction fees of a 2.9 percent commission plus 30 cents per successful card charge in the U.S. (fees vary in other markets).

The chief advantage of taking the paid product will be that teams will be able to customise how Radar works with their own transactions.

This will include a more complete set of data for teams that review transactions, and a more granular set of tools to determine where and when sales are reviewed, for example based on usage patterns or the size of the transaction. There are already a set of flags the work to note when a card is used in frequent succession across disparate geographies; but Manapat said that newer details such as analysing the speed at which payment details are entered and purchases are made will now also factor into how it flags transactions for review.

Similarly, teams will be able to determine the value at which a transaction needs to be flagged. This is the online equivalent of when certain purchases require or waive you to enter a PIN or provide a signature to seal the deal. (And it’s interesting to see that some e-commerce operations are potentially allowing some dodgy sales to happen simply to keep up the user experience for the majority of legitimate transactions.)

Users of the paid product will also be able to now use Radar to help with their overall management of how it handles fraud. This will include being able to keep lists of attributes, names and numbers that are scrutinised, and to check against them with analytics also created by Stripe to help identify trending issues, and to plan anti-fraud activities going forward.

Updated with further detail about Stripe’s funding.

Apr
05
2018
--

Google Cloud gives developers more insights into their networks

Google Cloud is launching a new feature today that will give its users a new way to monitor and optimize how their data flows between their servers in the Google Cloud and other Google Services, on-premises deployments and virtually any other internet endpoint. As the name implies, VPC Flow Logs are meant for businesses that already use Google’s Virtual Private Cloud features to isolate their resources from other users.

VPC Flow Logs monitors and logs all the network flows (both UDP and TCP) that are sent from and received by the virtual machines inside a VPC, including traffic between Google Cloud regions. All of that data can be exported to Stackdriver Logging or BigQuery, if you want to keep it in the Google Cloud, or you can use Cloud Pub/Sub to export it to other real-time analytics or security platforms. The data updates every five seconds and Google promises that using this service has no impact on the performance of your deployed applications.

As the company notes in today’s announcement, this will allow network operators to get far more insight into the details of how the Google network performs and to troubleshoot issues if they arise. In addition, it will allow them to optimize their network usage and costs by giving them more information about their global traffic.

All of this data is also quite useful for performing forensics when it looks like somebody may have gotten into your network, too. If that’s your main use case, though, you probably want to export your data to a specialized security information and event management (SIEM) platform from vendors like Splunk or ArcSight.

Apr
02
2018
--

MongoDB Data at Rest Encryption Using eCryptFS

In this post, we’ll look at MongoDB data at rest encryption using eCryptFS, and how to deploy a MongoDB server using encrypted data files.

When dealing with data, a good security policy should enforce the use of “no trivial” passwords, the use of encrypted connections and hopefully encrypted files on the disks.

Only the MongoDB Enterprise edition has an “engine encryption” feature. The Community edition and Percona Server for MongoDB don’t (yet). This is why I’m going to introduce a useful way to achieve data encryption at rest for MongoDB, using a simple but effective tool: eCryptFS.

eCryptFS is an enterprise-class stacked cryptographic filesystem for Linux. You can use it to encrypt partitions or even any folder that doesn’t use a partition of its own, no matter the underlying filesystem or partition type. For more information about this too, visit the official website: http://ecryptfs.org/.

I’m using Ubuntu 16.04 and I have Percona Server for MongoDB already installed on the system. The data directory (dbpath) is in /var/lib/mongodb.

Preparation of the encrypted directory

First, let’s stop mongod if it’s running:

sudo service mongod stop

Install eCryptFS:

sudo apt-get install ecryptfs-utils

Create two new directories:

sudo mkdir /datastore
sudo mkdir /var/lib/mongodb-encrypted

We’ll use the /datastore directory as the folder where we copy all the mongo’s files, and have them automatically encrypted. It’s also useful to test later that everything is working correctly. The folder /var/lib/mongodb_encrypted is the mount point we’ll use as the new data directory for mongod.

Mount the encrypted directory

Now it’s time to use eCryptFS to mount the /datastore folder and define it as encrypted. Launch the command as follows, choose a passphrase and respond to all the questions with the default proposed value. In a real case, choose the answers that best fit for you, and a complex passphrase:

root@psmdb1:~# sudo mount -t ecryptfs /datastore /var/lib/mongo-encrypted
Passphrase:
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32
2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
Selection [aes]:
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]:
Enable filename encryption (y/n) [n]:
Attempting to mount with the following options:
 ecryptfs_unlink_sigs
 ecryptfs_key_bytes=16
 ecryptfs_cipher=aes
 ecryptfs_sig=f946e4b85fd84010
Mounted eCryptfs

If you see Mounted eCryptfs as the last line, everything went well. Now you have the folder /datastore encrypted. Any file you create or copy into this folder is automatically encrypted by eCryptFS. Also, you have mounted the encrypted folder into the path /var/lib/mongo-encrypted.

For the sake of security, you can verify with the mount command that the directory is correctly mounted. You should see something similar to the following:

root@psmdb1:~# sudo mount | grep crypt
/datastore on /var/lib/mongo-encrypted type ecryptfs (rw,relatime,ecryptfs_sig=f946e4b85fd84010,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

Copy mongo files

sudo cp -r /var/lib/mongodb/* /var/lib/mongo-encrypted

We copy all the files from the existent mongo’s data directory into the new path.

Since we are working as root (or we used sudo -s at the beginning), we need to change the ownership of the files to the mongod user, the default user for the database server. Otherwise, mongod won’t start:

sudo chown -R mongod:mongod /var/lib/mongo-encrypted/

Modify mongo configuration

Before starting mongod, we have to change the configuration into /etc/mongod.conf to instruct the server to use the new folder. So, change the line with dbpath as follow and save the file:

dbpath=/var/lib/mongo-encrypted

Launch mongod and verify

So, it’s time to start mongod, connect with the mongo shell and verify that it’s working as usual:

root@psmdb1:~# sudo service mongod start

The server works correctly and is unaware of the encrypted files because eCryptFS itself takes care of encryption and decryption activities at a lower level. There’s a little price to pay in terms of performance, as in every system that uses encryption, but we won’t worry about that since our first goal is security. In any case, eCryptFS has some small footprint.

Now, let’s verify the files directly.

Since the encrypted folder is mounted and automatically managed by eCryptFS, we can see the content of the files. Let’s have a look:

root@psmdb1:~# cat /var/lib/mongo-encrypted/mongod.lock
6965

But if we look at the same file into /datastore, we see weird characters:

root@psmdb1:~# cat /datastore/mongod.lock
?0???k?"3DUfw`?Pp?Ku?????b?_CONSOLE?F?_?@??[?'?b??^??fZ?7

As expected.

Make encrypted dbpath persistent

Finally, if you want to automatically mount the encrypted directory at startup, add the following line into /etc/fstab:

/datastore /var/lib/mongo-encrypted ecryptfs defaults 0 0

Create the file .ecryptfsrc into /root directory with the following lines:

key=passphrase:passphrase_passwd_file=/root/passphrase.txt
ecryptfs_sig=f946e4b85fd84010
ecryptfs_cipher=aes
ecryptfs_key_bytes=16
ecryptfs_passthrough=n
ecryptfs_enable_filename_crypto=n

You can find the value of the variable ecryptfs_sig in the file /root/.ecryptfs/sig-cache.txt.

Create the file /root/passphrase.txt containing your secret passphrase. The format is as follows:

passphrase_passwd=mypassphrase

Now you can reboot the system and have the encrypted directory mounted at startup.

Tip: it is not a good idea to have a plain text file on your server with our passphrase. To have a better security level, you can place this file into a USB key (for example) that you can mount at startup, or you can use some sort of wallet tool to protect your passphrase.

Conclusion

Security is more and more a “must have” that customers are requesting of anyone managing their data. This how-to guide shows that achieving MongoDB data at rest encryption success is not so complicated.

The post MongoDB Data at Rest Encryption Using eCryptFS appeared first on Percona Database Performance Blog.

Mar
16
2018
--

Cloud security startup Zscaler opens at $27.50, a pop of 72% on Nasdaq, raising $192M in its IPO

The first post-billion, big tech IPO of the year has opened with a bang. Zscaler, a security startup that confidentially filed for an IPO last year, started trading this morning as ZS on Nasdaq at a price of $27.50/share. This was a pop of 71.9  percent on its opening price of $16, and speaks to a bullish moment for security startups and potentially public listings for tech companies in general.

That could bode well for Dropbox, Spotify and others that are planning or considering public listings in the coming weeks and months.

As of 3:45PM Eastern time, the stock has gone significantly higher and has just reached a peak of $30.61 as it approaches the end of its first day of trading. We’ll continue to monitor the price as the day continues to see how the stock does, and also hear from the company itself.

Initially, Zscaler had expected to sell 10 million shares at a range between $10 and $12 per share, but interest led the company to expand that to 12 million shares at a $13-15 range, which then moved up to $16 and Zscaler last night raising $192 million giving it a valuation of over $1.9 billion — a sign of strong interest in the investor community that it’s now hoping will follow through in its debut and beyond.

Zscaler is a specialist in an area called software-defined perimeter (SDP) services, which allow enterprises and other organizations to better control how they allow employees to access apps and specific services within their IT networks: the idea is that rather than giving access to the full network, employees are authenticated just for the apps that they specifically need for their work.

SDP architectures have become increasingly popular in recent years as a way of better mitigating security threats in networks where employees are using a variety of devices, including their own private mobile phones, to access data and apps in corporate networks and in the cloud — both of which have become routes for malicious hackers to breach systems.

SDP services are being adopted by the likes of Google, and are being built by a number of other tech companies, both those that are looking to provide more value-added services around existing cloud or other IT offerings, and those that are already playing in the area of security, including Cisco, Check Point Software, EMC, Fortinet, Intel, Juniper Networks, Palo Alto Networks, Symantec (which has been involved in IP lawsuits with Zscaler) and more — which speaks both of the opportunity and challenge in the market for Zscaler. Estimates of the value of the market range from $7.8 billion to $11 billion by 2023.

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