CISOs say they want data security that is flexible enough to work with hardened SIEM tools, but also capable of integrating as well. How does ALTR DSaaS make it easier to use APIs for integration? How is the result advantageous to reducing the risk of access to certain data or undertaking certain transactions with an application?
ALTR’s DSaaS offering was built as entirely cloud-native from the start, which makes it extremely flexible while integrating with existing systems in use by the modern enterprise. API connections can occur anywhere in the world and are not limited to customer data centers. This flexibility allows ALTR DSaaS to deliver real-time information about data access required anywhere – enabling security teams to respond quickly and accurately to potential threats. In addition to the extreme flexibility of integration, a cloud-native solution, like ALTR DSaaS, allows for a transparent update for clients pushing new features immediately without any involvement or downtime. Speed in updates means clients are always running with the most up to date software and patches, further reducing the risk of data access through their applications.
How does ALTR DSaaS institute controls prohibit unauthorized users—including internal staff—from accessing sensitive data? Does this conflict with or hinder CISOs or IT from doing the tasks they need to support and optimize the service?
ALTR DSaaS can reduce or eliminate both remote threats to data as well as direct (or insider) threats to data. With our ALTR DB service, remote access to data must flow through ALTR Smart Database Drivers, putting ALTR DSaaS in the critical path of data access. From this position, we limit data being returned through applications to end remote users. Direct access threats from internal staff, is a much harder problem to solve. This has traditionally relied upon AES encryption to protect this data. ALTR DSaaS provides an application-level tokenization solution for protecting at-rest data; the result is no data remaining for internal staff to access or see while directly accessing the database. As an application-level solution, ALTR DSaaS does not hinder DBAs, for example, from logging into the database server and doing their normal operations, but if they attempt to access data, they will only receive meaningless tokens.
Security monitoring plays a significant role in incident response. In the event of an attempted breach, what role does the ALTR service play in policy implementation, forensic activity, and intelligence sharing within an organization?
ALTR’s DSaaS solution plays a critical role in the security landscape of today. As an application is rolled out to production, it goes through a series of static code analysis tools, and eventually relies on runtime security tools and techniques to protect the application, once deployed. ALTR DSaaS extends this runtime protection to the SQL level and can monitor, govern, and protect data access to a database.
This new position in the security stack is a powerful place to enforce policy, whether it be location-based policy, access rate policy, or user/role-based. Each request to the database and its response is stored immutability into the ALTRChain, bringing additional insight and trust into the forensic process. The level of detail captured by ALTR DSaaS can be used not only by security teams during an incident to understand what happened, but can also be used to prove a breach did not occur. These insights can be surfaced quickly and shared with compliance, legal, or other areas of the business involved with the incident.
Companies are not always comfortable with the indirect relationship to cybersecurity risk that migration to the cloud presents. How does vendor-based protection like ALTR DSaaS mediate cloud data security and protection?
One of the initial steps in creating a cloud security framework is to avoid the temptation of vendor lock-in for security within a particular cloud provider. By using a cloud-agnostic approach, like ALTR DSaaS, your security lives with your application and your code, not your infrastructure.
This advancement finally makes security portable between clouds, giving the ultimate flexibility to move between cloud providers. A reduction in risk to your cloud migration is gained by not utilizing cloud-specific services, which ultimately means the cloud providers see less of your data and workloads. Additionally, as the cloud continues to abstract more and more infrastructure, including the push to serverless computing, embedding security into your application code becomes the only point where you can effectively secure your cloud-based workloads. A security solution, like ALTR DSaaS, can prevent unwanted parties from having access to your data and provide ultimate visibility in an environment where you cannot control much of anything.
SaaS vendors have been criticized for not helping customers comply with data-privacy mandates such as GDPR and CCPA, which require configuration of features like encryption, data purging, and data logging to ensure compliance. How does the ALTR service approach this?
The good thing about ALTR is that it instruments your application to handle the demands of existing regulations while allowing you to easily make changes as those regulations evolve, without having to touch the application itself. ALTR’s policy toolkit, controlled through our console, includes full tamper-resistant record-keeping around data access, and control of data using application-friendly dynamic masking, and can be maintained by compliance experts either inside of your company or provided by ALTR through our healthy ecosystem of service partners.
James Beecham is a Computer Engineer and Entrepreneur. James co-founded ALTR, an information security startup, where he currently works as CTO and has been issued two patents on ALTR’s proprietary blockchain technology. James graduated from the University of Texas at Austin with a degree in Electrical and Computer Engineering, where his focus was embedded systems. Previously, James worked at Dash Financial as the technology R&D lead, where he developed risk layers and algorithmic protocols for Dash’s electronic trading platform. He also worked as an embedded systems engineer at Texas Memory Systems before its acquisition by IBM.