Machine Learning to Identify Insider Threats
speak of insider threats various connotations come to mind. Perhaps you
think of whistleblowers attempting to damage an organization by leaking
proprietary information or maybe employees seeking to profit through
persistent industrial espionage. While these examples certainly represent
a credible danger, there’s a category of risk that includes a much more
significant threat — malicious outsiders who penetrate systems by
stealing legitimate credentials and thus appear as insiders.
Given that the most important information resides in databases,
organizations are increasingly turning their focus toward databases
security technologies. To defend databases from attackers using stolen
credentials, the industry is beginning to adopt a new security paradigm
based on machine learning and behavior analysis.
where your most valuable data assets are located is an essential first
step in protecting them. Most security practices begin with a discovery
phase to identify the organizations most critical data. This will ensure
that the security practices will protect these assets. As an information
asset residing at the core of every critical business process, databases
are the principle location for high-value organizational data.
Keeping track of databases, and the associated data they host, turns out
to be a significant challenge. Most organizations lack the necessary
tools to track the location of sensitive data repositories and how
they’re being used. The issue is far larger than a single or even a
periodic initiative to create an inventory of sensitive assets. Given the
dynamic nature of organizational data, the way it is being used, stored,
and eventually destroyed is constantly in flux and needs to be tracked on
a continuous basis.
defense-in-depth strategy seeks to reduce the SQL injection attack
surface at each tier of the architecture. Rather than focusing on a
"silver bullet" solution in the Web or application tier, a comprehensive
defense-in-depth strategy addresses the entire architecture including the
database tier – which is the ultimate goal of the attack.
A SQL injection attack that has penetrated the perimeter, exploited the
application, and reached the database tier is “knocking at the door” of
the database. If not immediately identified, alarmed, and contained at
that point a breach is imminent. Once the SQL injection attack is
contained and the specific vulnerability identified, patches can be
applied as part of an iterative mitigation process to continually reduce
critical your web applications are as secure as possible while also
staying on schedule and within budget. Often organizations turn to
penetration testing and application code scanning to identify security
vulnerabilities. While neither approach is perfect, they both do find
lots of areas that your developers need to tighten up (and just as
importantly, they keep the compliance folks happy). Still, there’s no
question that there are important vulnerabilities that are being missed.
The challenge is how to find the most risky ones without blowing the
budget or schedule.
SQL fragments injected into a Web application has proven extremely
challenging. There are several tacks enterprises can take – prevention,
remediation, and mitigation. When implementing prevention and remediation
efforts, the enterprise strives to develop secure code and/or encrypt
confidential data stored in the database. However, these are not always