New york oracle users group 2013 spring general meeting ulf mattsson

Editor's Notes

• #28: Risk Adjusted Data Protection simply means that you should protect data based on the risk of the sensitive data.You can determine your risk by deciding what is the value of the data to the bad guys and what is its exposure. For valuable data with wide exposure, such as a credit card number or SSN, you can protect with strong encryption like AES or by tokenizing. For your data that might have little or no value, but is still widely exposed, you can protect with monitoring or Data Type Preserving Encryption.This chart shows several approaches to protect sensitive data along with a set of criteria that we have found useful when comparing the merits of each method.- Performance and security are self explanatory Storage refers to the impact that a method has on storage. For example, strong encryption will require adding padding to the crypto text so that the final data will be larger than the original. When a data store is billions of records this can have an impact on the cost of the solution. Transparency refers to the degree to which a protection method effects business processes, applications, databases and any architecture. A protection method that is not transparent will require remediation to systems that are being protected. This could translate to higher protection costs. Tokenization has been gaining popularity due to it’s high transparent characteristics that are seen to reduce protection costs.For example, a system that has no data protection will have optimal performance because you’re not protecting anything and there’s no increased storage. It will require no system remediation, but it will have no security. This is basically the status quo.By contrast, using tokenization, you are not going to have any performance impact, or any increased storage because we are creating a unique token of the same type and length as the original data. With regard to security, tokenization gives you optimum security, and we’ll get into this later. From a transparency perspective, while it is not as transparent as using no protection, among other things, you are not introducing changes to your database schema.The message here really is that, as you change your security profile, there are a number of other factors that you’ll need to take into account.
• #32: Joel – what do you do with the nodes - elastic
• #33: Joel – what do you do with the nodes - elastic
• #34: Joel – what do you do with the nodes - elastic
• #37: Everything we do depends on the policy. The security policy is the foundation for protecting data. It is usually managed by the Security Officer. Think of it as the glue that binds distributed data protection throughout the enterprise. You can have one policy or many policies , but every policy includes the following core components:What: First you need to identify what you need to protect, i.e. credit card data, social security number and user names and passwords . This is the data element. And you can think of a data element as simply a label, such as CCN. It simply says I’m protecting credit card data.Who: This is your access control. Once you know what you want to protect, the “Who” determines who has access to the data and who doesn’t. We do this through Roles and we associate Members with Roles. We can take members from a number of sources, such as LDAP or Active Directory, a database or a flat file.When: We have a time parameter in our policy that enables us to control the day and the time of day when sensitive data can and cannot be accessed. It is completely customizable by role.Where: Where does the data exist? This is an important property that sets up apart. We need to know this to be able to deploy policy to our agent that enforces policy on the protection point. You might have many, many protection points, so we need to know where the policy needs to be deployed. It also enables us to pinpoint where unauthorized attempts at accessing sensitive data are taking place. And, when we talk about key management, we are the only platform that tracks where keys have been deployed.How: This is what everyone focuses on – how data is protected. This is another differentiator for us. We are not just a strong encryption vendor. We expanded our capabilities and we have a whole host of methods for protecting sensitive data. We do something that we call Risk Adjusted Data Protection that allows you to scale up or scale down your data protection based on the sensitivity of the data you’re trying to protect. We will discuss this later.Audit: Lastly, we have an auditing function. In the policy, the security officer sets up audit requirements that are carried out by the policy enforcement process. You can audit authorized or unauthorized users in addition to controlling operations such as insert, update and delete in a database scenario. You can make the Policy is as customized as you want it to be.This is policy based data security.
• #39: Joel – what do you do with the nodes - elastic