ObserveIT - Take Action Now. Join our more than 1500 happy customers.

• User behavior analytics (USER RISK SCORING)
• Remote vendors monitoring
• Privilege users monitoring
• Business employees monitoring
• Customized to full visibility (PRIVACY)
• Full search and reports
• Real time alerts
• Built-in rich alert rules library (OUT OF THE BOX!)
• Prevention/blocking and educational notification
• GDPR enable policies and reports
• Windows/Unix/Linux/Mac
• Reduce risk by ~70%(*)
• Rapid Deployment !

Download ObserveIT and get started | ObserveIT

(*) contact us for research information

Real Time warning , blocking and prevention of risky user activity

Many organizations are facing the challenge if educating their employs on internal policies , policies that are related to IT activity as :

• Printing
• Sharing and Open Document
• Insert USB
• Copy files to USB
• Visiting sensitive sites
• Start/Stop Windows Services
• Reboot Windows
• And many more….  The list is actually endless

The way it is done today in most organization is by “orientation session” in which the new employee learns about the “don’t do".

However, the challenge is that

• Many employees tend to forget policies
• Policies may change
• New policies will need to be conveyed to employees

And when the employee violates a policy, a real time notification is requited .

ObserveIT User Behavior Analysis (UBA) provides this need by notifying the user in real time when the user performs a bad action or violates a policy .

For example, if the user insert USB , his desktop will be blocked and he will see a windows as below (all messages can be customized). The user will be also to add comment (excuse) for this activity alert.

If the user open the Active Directory management tool, he will see a window that also direct him to the URL link of the company’s internal policy:

To schedule a demo, please contact me via LinkedIn or Twitter

Insider Threat - How to get started

Global and international risk analysis show that the largest risk in organizations comes from insider threat and not from external cyber-attacks. In most cases, it’s not a malicious employee but someone that was manipulated by social engineering techniques by another college or external person in order to gain insider access. Theft of intellectual property is an increasing threat to organizations, and can go unnoticed for months or even years.

Another common insider theft is when employees taking proprietary information when they believe they will be, or are, searching for a new job.

Current or former employees, contractors, or other business partners who have authorized access to an organization's data pose one of the greatest risks.  What is an insider threat? It's the risk of misuse of access privileges to steal, leak or destroy customer, company or employee data.  So how do you actually detect questionable actions and access abuse once a user logs in?  The large volume of data generated through normal user activities and lack of visibility into actual user behavior makes detecting insider based exposures of sensitive data nearly impossible. Insider Threats represent a major security blind-spot where an increasing number of today’s security incidents occur.

Addressing Insider Threat requires that organizations detect abnormal user behavior and educate their employees about the risks of protecting their accounts being used as a conduit for others to obtain sensitive data. Most organizations rely on system logs from applications and devices that typically contain hundreds or thousands of discrete events in obscure technical language, making it nearly impossible to determine what a user actually did, let alone proactively determine if their credentials were hijacked.

With ObserveIT’s user activity monitoring solution you’ll know when users put your business at risk. The software can detect and alert on application usage that indicate insider risks becoming insider threats.  ObserveIT screen scrapes all activity and indexes the textual information on the screen, so you’ll know what’s happening in all applications, even applications that do not generate logs. You’ll have a clear picture, literally, of all user actions across your entire enterprise including web apps, legacy applications, and custom or homegrown applications.  

For signs of heightened insider threat you can setup alerts and generate reports to detect abnormal behavior with how users are interacting with important data as well as have a visual playback of exactly what each user did. This provides the early warning system needed to reduce your risk and strengthen your security posture.

 How to get started

For an organization to combat (Detect, Mitigate, Prevent) insider threats, it needs to establish a comprehensive and integrated insider threat program that is comprised of individuals from various departments, business units and supporting functions. Because each organization is unique, the structure of the insider threat program may be different. The end result for any insider threat program is the identification of suspicious or malicious activities and behavioral indicators by the insider, as these are crucial in limiting or neutralizing the potential damage that may be caused by an insider threats.

Starting the insider threat program is a business initiative and will require buy in at the executive level because it will touch almost every part of the organization, including security, IT, HR as well as legal and privacy. Building consensus at the executive level for all of the business units mentioned above will enable those managing the insider threat program to have the appropriate oversight. 

THE RISK THAT SECURITY ADMINISTRATORS ARE EXPOSED TO WHEN IGNORING REAL TIME USER ACTIVITY RECORDING AND BEHAVIOR ANALYSIS

Based on Association of certified fraud Examiners – 2013 Report 

Security administrators are exposed to the following Fraud landscape.
The study is based on 94 countries and 1400 cases

The global worldwide actual fraud in 2013 was 3.8 Trillion $ .

Since most frauds today are done via computes , then most of  those frauds could be detected via real time user activity detection and recording , following by real time user anomalies analysis based on the user’s attributes as:

 Title, department , Location, Age, Gender, Seniority etc…

 

Frauds by company type:

·     40% of the frauds that were analyzed were done in private companies

·     28% public

·     17% governments

 

By company size

·     31% of frauds in companies with less than 100 employees

·     20.6% of frauds in companies with more than 10K employees

 

Analysis By Sectors

·     16.7% in banks and finance institutes

·     10.3% in governments and public

 

Analysis of fraud Types

·     25.1% – corruption

·     26.1% – billing

·     12% - Salaries

 

Geographic

·     USA : 25.1%

·     Asia : 51%

 

By Employee Type:

·     Manager : 573K $ in average incident

·     Employee: 60K $ in average incident

 

By Departments/divisions:

·     Finance:293 cases, 183k$ (avg) / case

·     Operations: 232 cases , 100k$ (avg) / case

·     Legal: 8 cases , 180k$ (avg) / case

Seniority

·     More than 10 years in the company: 229k$ of average fraud size

·     Less than 1 year in the company: 25k$ of average fraud size

Senior workers are most trusted in the company.

From the seniority analysis we can learn that trust is a main RISK factor for frauds

 

Gender:

·     65% - men 200k$/case (take more risks in life)

Men are more than women in management positions

·     35% - women 91k$/case (more conservative)

 

Cases by Age:

·     19.6%   41-45

·     3.1%    >60

·     5.8%   < 26

 

Fraud size by age

·     600k$    51-55

·     25k$       < 26

 

Education

·     75% Academic

·     25% - non Academic 

 

Fraud size by education

·     300k$ Academic

·     75k$ - non Academic

58% of fraud cases done by one person 

Fraud size by collaboration:

·     One person: 100k$

·     Collaboration : 250k$  

 

Which Controls can help you to reduce risk (from most effective to least):

·     Control tools : Real Time User Activity Monitoring and behaviors analytics

·      “Management Review” reduces the damage by 45.9% (average)

·     Hot Line

 

Bottom line:

·     5% of revenue is lost due of frauds  (3.5T$ in 2013 vs 2.9T$ in 2010)

·     Average fraud is 140k$

·     20% of cases over 1 million $

·     Discovered by auditors 18 months after the fraud started

 

Apache Management

Configure apache to listen on port other than 80
Open httpd.conf file in your text editor. Find this line:

Listen 80

and change it

Listen 8079

After change, save it and restart apache.

Privileged User Monitoring for SOX Compliance

Many enterprises are facing the SOX compliance challenge of monitoring all of the data activity of their most privileged users. This page highlights several of these challenges and how they can be addressed by a comprehensive database activity auditing solution.

Sarbanes-Oxley (SOX) IT controls address the integrity of databases that store sensitive financial and business information. In particular, new SOX requirements have shifted the focus from merely understanding who has access to information to continuous monitoring of database activity. These requirements target high risk database activities:

• Privileged user behavior
• Direct access to sensitive data stores
• User privilege escalation
• Failed login
• Failed database operations
• And more

Finally, while database applications like DB2, Oracle, SQL Server, and Sybase rightly

attract most of the attention, the problem invariably extends to other sensitive data stores—file server-resident financial, legal, strategic, and spreadsheet documents being the foremost examples.

SOX Section 404 demands that companies

• evaluate the adequacy of internal controls as they relate to financial reporting
• institute new controls as necessary, and
• perform and reportan assessment of these controls on an annual basis.

 

 

In short, Section 404 says, "Management must ensure that appropriate internal controls for financial

reporting are in place."

 

Furthermore, Section 404 requires not only that corporate and IT officers immediately put in

place internal controls to protect the integrity of financial data (and, by implication, all systems that access that data), but also that the organization must be able to demonstrate that appropriate controls are in place.

 

At first glance it is quite obvious that the full access credentials accorded to DBAs and system administrators creates a significant vulnerability for an enterprise’s data simply because these privileged users have access to all or a significant fraction of your data.

 

However, privileged users are normally highly valued and trusted individuals who are indispensable to the day-to-day workings of your data environment, and they generally do not respond well to being told by an IT auditor that they are a threat that must be monitored. In reality, with most enterprises working to enforce segregation of duties, most DBAs and System Administrators expect their activity to be monitored and have no issue with this simply because they don’t intend to do anything wrong.

 

The problem with this approach is that it is of critical importance for DBAs to have access to database log facilities, so curtailing their privileges effectively curtails their productivity and makes their job more difficult.

This is precisely the challenge that enterprises are facing with the SOX section 404 mandate to monitor the activity, particularly database activity, of their DBAs and other privileged users. The problem arises because it makes no sense to monitor a DBA with full privileges by using the log facilities within the database applications, because their privileges will allow them to cover their tracks by deleting or otherwise altering the logs.

 

So many enterprises are resorting to curtailing their DBAs’ privileges to prevent them from having any access to the log facilities. The problem with this approach is that DBAs use the database log facilities as a debug tool in order to do their job, so curtailing their privileges effectively curtails their productivity and makes their job more difficult.

Corporate officers, IT auditors, and database administrators find a variety of challenges in the requirement to audit all privileged user activity, which typically ranges over a variety of platforms, applications, and data stores. This page provides detailed analysis of a number of the issues associated with privileged user monitoring.

 

SOX-Mandated Database Activity Monitoring

From a data administrator’s viewpoint, SOX-related monitoring requirements are quite broad, but they can be distilled under five key headings:

Monitoring database access by privileged users—DBAs and system administrators, for example

As the title of this paper implies, privileged user monitoring is the primary objective of most SOX database auditing projects. Additional requirements generally relate to specific activities initiated by privileged users or, potentially, users masquerading as privileged users for malicious purposes.

Enterprises must audit all activity by administrators and other privileged userIDs, and, perhaps more importantly, must be able to retrieve, examine, analyze, and report on this piece of the audit trail.

Enterprises working to comply with this requirement have found that in practice it can be difficult to implement due to a variety of problems:

• The very users they are monitoring typically have full administrator credentials and can cover their tracks by modifying or deleting the logs being used to monitor them.
• Privileged user credentials can be restricted to prevent log access, but this results in lowered productivity or creates an adversarial relationship with unhappy DBAs.
• Many enterprises employ databases from several different database vendors, which require individual expertise on each database’s log capabilities and makes log consolidation into useful reports a near impossibility.

A comprehensive database activity auditing solution must address all of these problems.

 

Monitoring changes in privileges

Not all users utilize privileged credentials all the time. Many times users will use privileged credentials on an as needed basis to perform specific tasks. It is imperative to track when these privilege escalation events occur and maintain and regularly view reports of this activity in order to verify the legitimacy of these events.

In order to attest to the integrity of sensitive data, it is imperative to know what is happening in the user community.

Have new users been defined, or an existing user de-provisioned? Have a user’s privileges been escalated or revoked? A complete database activity auditing solution will provide the necessary visibility in to these types of transactions without requiring auditors to search through seemingly endless database log files.

 

 

Monitoring access failures

Enterprises must know when login attempts fail, and also when data access attempts are unsuccessful. Failed access events are an indication that something is not right. Application data access attempts, in particular, should never fail.

There are various definitions of invalid logical access attempts. These two are most common:

• unsuccessful attempt to access a resource

• invalid or failed login

An effective database activity monitoring solution must be capable of capturing both classes of failed access operation.

 

 

Monitoring schema changes

To ensure data integrity, you must be able to track changes to compliance-related data structures. Monitoring, logging, and reporting on data structure changes not only permits you to satisfy routine auditing requirements, but also to identify anomalous, unscheduled activity.

 

 

Monitoring direct data access

Another common requirement is to track any direct access to sensitive system and data tables. Since direct access operations are uncommon in procedural applications, it is important to capture an audit trail of such activities. Alternative tracking techniques, including triggers and local agents, are expensive and do not scale.

 

Furthermore, a complete database activity auditing solution will capture the necessary detail in the audit trail to not only show that a direct SQL event occurred, but also who initiated the event (what user ID), what source IP address originated the event, and precisely what content was affected by the event (database, tables, columns, and rows).

 

In fact, an ideal database activity auditing solution will permit the exact reconstruction of any SQL transaction associated with any of the events stored in its audit trail repository.




Additional Key SOX Activity Auditing Challenges


Database managers, auditors, and security officers bear the burden of satisfying regulatory and internal audit demands for SOX compliance. Numerous trouble spots persist, in addition to privileged user monitoring. Key challenges include:

• Consistent monitoring across all databases –Large enterprises often deploy database products from multiple vendors—DB2, Oracle, SQL Server, Sybase, and so on. Until recently, monitoring access activity across varied databases in a consistent, comprehensive, and normalized way has been effectively impossible. Failed response codes, for example, differ from one product toanother, or even from version to version.

• Inadequate database logs, resulting in non-compliance –Both native logging (database and/or server) and log consolidation tools—ignoring their well-documented performance penalties—invariably fall short of SOX auditing requirements. These solutions yield paradoxical results: both log data overload and defacto non-compliance, the
worst of all worlds.

• Inadequate data management and reporting –SOX compliance includes the demonstrable, repeatable ability to reconstruct event flows by finding and extracting one or more critical events from the current or archived audit trail.
Writing filtering tools for this purpose is very difficult. Furthermore, identifying the key events is just the first of many tasks, which may include storing such events for rapid on-line examination (typically for 60-90 days), generating scheduled reports for auditors and other stakeholders, supporting audit trail search operations, and certifying audit log security.


• Inadequate analytics and alerting –The spirit of SOX adherence also includes identifying and tracking access events that signal potential fraud or other data misuse. For example, it may be necessary to detect and alert on outlier events such as N-time failed logins, large return sets, or statistically rare data access operations. Alerts may
also require integration with other security event management tools. Today’s database tools lack the analytics to support a meaningful alert detection and response system.


• Segregation of duties requirement –A special challenge arises when collecting and maintaining audit trail and report data on privileged users (DBAs, for example)—data that is typically stored on systems managed by these same privileged users. Native database logging and agent-based solutions exhibit this deficiency, which stands in direct violation of both SOX and common sense. The segregation of duties standard dictates that privileged user monitoring data be stored outside the control of the user or users being monitored.

 

PCI Logging and Auditing Compliance for Custom Applications by ObserveIT (www.ObserveIT.com)

Source: http://www.observeit.com/

PCI-DSS Requirement 10: Logging and Auditing

PCI-DSS Requirement 10 (“Track and monitor all access to network resources and cardholder data”) is all about using logs for vulnerability management and event forensics. These logs must record every time someone accesses regulated data (including cardholder data and log data) to enable a “who-did-what-and-when” audit trail. This requires means implementing a comprehensive system to log every time any employee or remote vendor accesses a server or application which processes protected data.
This is an ongoing requirement that calls for continuous monitoring and review (log review, the key part of Requirement 10.6, is explicitly mandated to occur on a daily basis). Furthermore, according to the Requirement, these records must be immediately available for three months and stored for later retrieval for one year.

The Challenge of PCI-DSS Requirement 10 for Custom Applications

Complying with this requirement may be very difficult for custom applications that don’t already incorporate comprehensive logging. Even if the application source code is available – and relevant developers are on hand – implementing the mandated logging into these applications may require an extremely difficult, expensive and risky undertaking.
There is an easier way.

An Elegant PCI Logging Solution for Custom Applications

Achieving PCI logging and auditing compliance for custom applications no longer requires touching a line of custom code. Instead, software known as Screen Session Recording or User Activity Monitoring can help you satisfy compliance requirements by monitoring and recording every user action performed within custom applications – just like a video camera watching all users’ screen activity from over their shoulder. Furthermore, these systems generate text-searchable logs which are linked to the screen recordings.
By simply installing agent software on every machine with direct or indirect access to custom applications, all Requirement 10 compliance needs are instantly met because every user action in every custom application is recorded (in video) and logged (in text logs).
The daily review requirement is neatly met by the User Activity Monitoring system as well: alerts and reports can be created to include any activity involving protected data, making it a simple matter to review a day’s worth of relevant access to the data. Predefined compliance reports supplied with these systems can show all relevant actions, with links to video replay for further clarification, allowing almost out-of-the-box compliance.
In conclusion, the demands of PCI-DSS Requirement 10, which have been intimidating IT teams and management teams alike, are easily met with a suitable User Activity Monitoring system – even for custom applications for which no built-in logging exists. Auditors appreciate the user friendliness of these systems which combine instant keyword search with visual recordings of every user action. Daily log reviews are fast and easy with predefined compliance reports.

PCI DSS Requirement Section 12: Maintain an Information Security Policy

A strong security policy sets the tone for security affecting an organization’s entire company, and it

informs employees of their expected duties related to security. All employees should be aware of the

sensitivity of cardholder data and their responsibilities for protecting it.

Requirement 12: Maintain a policy that addresses information security for all personnel

 

12.1 Establish, publish, maintain, and disseminate a security policy that addresses all PCI DSS

requirements, includes an annual process for identifying vulnerabilities and formally assessing

risks, and includes a review at least once a year and when the environment changes.

 

12.2 Develop daily operational security procedures that are consistent with requirements in PCI DSS.

 

12.3 Develop usage policies for critical technologies to define their proper use by all personnel. These

include remote access, wireless, removable electronic media, laptops, tablets, handheld devices,

email and Internet.

 

12.4 Ensure that the security policy and procedures clearly define information security responsibilities

for all personnel.

 

12.5 Assign to an individual or team information security responsibilities defined by 12.5 subsections.

 

12.6 Implement a formal security awareness program to make all personnel aware of the importance of

cardholder data security.

 

12.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal sources.

Example screening includes previous employment history, criminal record, credit history, and

reference checks.

12.8 If cardholder data is shared with service providers, maintain policies and procedures to formally

identify service provider responsibilities for securing cardholder data, and monitor service
providers’ PCI DSS compliance status at least annually.

 12.9 Implement an incident response plan. Be prepared to respond immediately to a system breach.

 

PCI DSS Requirement (Section 10): Track and monitor all access to network resources and cardholder data

10. Track and monitor all access to network resources and cardholder data

10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

10.2 Implement automated audit trails to reconstruct the following events: all individual user accesses to cardholder data, all actions taken by any individual with root or administrative privileges, access to all audit trails, invalid logical access attempts, use of identification and authentication mechanisms, initialization of the audit logs, and creation and deletion of system-level objects.

10.3 Record at least the following audit trail entries for all system components for each event: user identification, type of event, date and time, success or failure indication, origination of event, and identity or name of affected data, system component, or resource.

10.4 Synchronize all critical system clocks and times.

10.5 Secure audit trails so they cannot be altered.

10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).

10.7 Retain audit trail for at least one year, with a minimum of three months available online.

PCI DSS Requirement (Section 8): User & Password Policy

8.1 Assign all users a unique ID before allowing them to access system components

or cardholder data.

8.2 In addition to assigning a unique ID, employ at least one of the following methods

to authenticate all users:

- Password or passphrase

- Two-factor authentication (for example, token devices, smart cards,

biometrics, or public keys)

8.3 Incorporate two-factor authentication for remote access (network-level access

originating from outside the network) to the network by employees, administrators,

and third parties. Use technologies such as remote authentication and dial-in

service (RADIUS); terminal access controller access control system (TACACS)

with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.

8.4 Render all passwords unreadable during transmission and storage on all system

components using strong cryptography

8.5 Ensure proper user authentication and password management for non-consumer

users and administrators on all system components as follows:

8.5.1Control addition, deletion, and modification of user IDs, credentials, and

other identifier objects.

8.5.2Verify user identity before performing password resets.

8.5.3Set first-time passwords to a unique value for each user and change

immediately after the first use.

8.5.4Immediately revoke access for any terminated users.

8.5.5Remove/disable inactive user accounts at least every 90 days.

8.5.6Enable accounts used by vendors for remote maintenance only during the

time period needed.

8.5.7Communicate password procedures and policies to all users who have

access to cardholder data. Add-on Add-on

8.5.8Do not use group, shared, or generic accounts and passwords.

8.5.9Change user passwords at least every 90 days.

8.5.10Require a minimum password length of at least seven characters.

8.5.11Use passwords containing both numeric and alphabetic characters.

8.5.12Do not allow an individual to submit a new password that is the same as

any of the last four passwords he or she has used.

8.5.13Limit repeated access attempts by locking out the user ID after not more

than six attempts.

8.5.14Set the lockout duration to a minimum of 30 minutes or until administrator

enables the user ID.

8.5.15If a session has been idle for more than 15 minutes, require the user to reenter

the password to re-activate the terminal.

8.5.16Authenticate all access to any database containing cardholder data. This

includes access by applications, administrators, and all other users.