Alex Varshavsky, CEO, Talksum
Target announced last week that Chairman, President, and CEO Gregg Steinhafel has been ousted nearly five months after the retailer disclosed a massive data breach, which has hurt its reputation among customers and hammered its business. According to an Associated Press (AP) article, “experts say his departure marks the first CEO of a major corporation to resign in the wake of a data breach and underscores how CEOs are now becoming more at risk in an era when such breaches have become common.”
The Talksum Data Stream Router (TDSR) provides a mechanism for protection against security breaches. First of all, security revolves around the continued stability of a system within boundaries. A “security event” occurs when the stability of a boundary has been compromised. Ultimately, you need to know “what changed” and whether the changes were expected or unexpected. This is what the TDSR was built to do.
A couple of questions arise once an unexpected change occurs:
- Who is attempting to get unauthorized remote access from where, and how frequently?
- Why are login attempts failing on some hosts?
- Who is attempting to get unauthorized local (PAM) access from where, and how frequently?
In the first case above, the TDSR first looks at different layers within the data center, for example, the network layer, virtual hosts layer, and applications layer. Then it looks across sources within those layers and applies filters as necessary. For example, if a “filter 0” defines the source as an SSH, then a message is sent to a “filter 1,” which looks for a tag that equals “failed” to alert a failure. In that instance, the user, IP address, and time are immediately sent to the alerting database. In this case, the TDSR can show, in real time, how many IP addresses, for example, tried to attack the system.
In the second scenario, the TDSR looks at the physical host(s) and applications to filter anomalies that cause login attempt failures. If a “filter 0” defines its source as “NSLCD,” then it sends the information to “filter 1” that, upon a “connection_error” tag, writes a detailed message that may include time, the user, the error, the IP address, and so on, to the alerting system.
In the third example, the TDSR looks at the virtual host(s) and virtual applications, the physical host(s), and applications to filter local authentication errors. If a “filter 0” defines its source as “PAM,” then it sends the information to “filter 1” that, upon a “local_auth_error” tag writes a detailed alert that may include time, the user, the error, the IP address, and so on, to the alerting system.
These are just a few of many example security use cases that the TDSR can handle. The Talksum product uses a new approach to break down data silos to provide real-time actionability in response to security, compliancy, and compatibility-related information. In addition, the TDSR includes foundational components for regulatory compliance, government standards, and policy control, so it is easy to keep pace with on-going changes.