Category Archives: Security Learning

Random Thoughts, Security Learning

Sec-Intel with Twitter Trends

Gallery Leave a comment

Recently came across an interesting topic on the Splunk Blog – Visit http://blogs.splunk.com/2010/06/23/track-twitter-world-cup-sentiment-with-splunk/. To summarize this blog post, there is a Twitter App available for Splunk that lets you stream the Popular topics on Twitter. It collects Twitter Trends and presents a dashboard on the Splunk front end. All it requires is Splunk with Twitter App Plugin and a Twitter Account to track streams. For people without Splunk, the answer lies in customizing your Log Management Solutions to do something similar. The big question in my mind is “How would it be if we use this cool feature of Splunk to do Security Intelligence gathering and from there on, use this contextual data to perform Security Investigation and Analysis”?

Investigation in most cases is something very reactive based on what is seen in the logs or what is going on the network at a given time. Would it be possible for Investigation to be driven using Security Intelligence? In a country’s Intelligence Bureau, this is exactly what happens. Using data from the “chatter” and gauging the potential mood and the probability of a National threat. Scaling it down to an Enterprise level should be easy and very much do-able I guess. Several organizations are dependent on “public face”. One rotten apple leaking stuff from inside on some social media network would cause significant damage to the company’s reputation. This is where such Intelligence Gathering from the Internet helps. There are several implementation difficulties, but it is something worth considering on a case by case basis.

So What do you think? Is gleaning Security Intelligence from Social Media promising? What are the possible concerns regarding Privacy, Legislation, etc? Can Security Intelligence with Twitter Trends the next thing to do? Comment ON!!!

 

 [pdf]Save as PDF[/pdf]

Security Learning

Rules Rule In SIEM Kingdom!!!

Gallery 3 Comments

Are you new to SIEM?
Are you trying to write a Correlation Rule in SIEM and don’t know where to start?
Are you stuck with several jargons from the SIEM Administrator guide?
If your answer is “YES” to any one of the above questions, please continue.

Rules are the staple ingredient for any SIEM tool or Technology. A Rule is nothing but a set of logical instructions for a System to follow before it determines What to do and What not to do. As we all know, SIEM is a passive system. All it does is a pattern matching of the Logs received and follows the instructions on what to do (trigger) and what not to do (Not Trigger). This pattern matcher is also called as Correlation Rules or Real time Rules. These Correlation Rules are nothing but “your visualization of how an attack would look in an IT Infra”.

Generally, Rule Writing or Rule Development is a process similar to SDLC.
It all starts with the Requirements Phase.
Requirement Phase: In this phase, the Rule Author should collect the exact requirements of putting a rule in place. This requirements should also tell what is the “Intent” of the rule. It also captures the Response such a Rule Trigger would elicit. It is at this Requirements Phase, where the “visualization” actually starts. Remember, without a goal your Rules will not mean anything.

Once you gather the requirements, you enter into the Design phase.
Design Phase: In the design phase, you do the rough skeletal layout of the rule itself. Things like,

  • What logs to use for creating this specific rule?
  • What log attribute is more suitable for rule trigger?
  • What are the various attributes to collect/represent?
  • What type of rule to write?
  • What type of alerting to be configured? (Read Email, SNMP Traps, Dashboard Trigger, Response Action etc)

are laid out in this phase. This is the Most crucial phase. When it comes to Selecting Rule Types, you need to know what are all the available features from your SIEM tool or Technology. Generally as an All-Purpose guide, I would broadly classify the rules for any SIEM tool or Technology into the following:

1. Single Event Rule – If Condition 1, 2, 3 up to N match, trigger. Typically used rule type as it is straight forward pattern matching of Event Type, Event ID, IP etc.
2. Many to One or One to Many Rules – If a Condition matches and One Source Several Targets or One Target Several Sources scenarios are in play
3. Cause and Effect Rules or “Followed by” Rules or Sequential Rules – If Condition A matches and leads to Condition B. This will typically we a “Scan Followed with an Exploit” type scenarios, “Password Guessing Failure followed by Successful login” type scenarios etc.
4. Transitive Rules or Tracking Rules – If Condition A matches for Attacker to Machine A and within some time, Machine A becomes the Attacker for Machine B (again matching Condition A). This is typically used in Worm/Malware Outbreak Scenarios. Here, the Target in the first event becomes the Source in the second event.
5. Trending Rules – These rules are tracking several Conditions over a time period, based on thresholds. This happens in DoS or DDoS Scenarios.

In the design phase, the selection of the above happens. If this Rule Type selection is messed up here, you will have to revisit the Requirements phase again. Hence it is important to understand and choose wisely.

Now that we have got the requirements and the design out, we can move to the Development phase.
Development Phase: This is where we actually write the rule. Remember, once the logical understanding is there for the Conditions required to match (generally using Boolean Operators), writing a Rule is very simple and straightforward (of course you need to know the SIEM Tool Menus to do so)

Finally, Testing Phase and Deployment Phase follow. Testing is critical to validate the logic involved in the Rule. Simulating the Rule Conditions in Development Environment/Testing Environment will help to iron out the Chinks in the Rule.

Finally, Post Implementation Phase kicks in.
Post Implementation Phase: Once the rule is implemented, we need to manage them. By manage, I mean ensure that the rule is tightened based on feedback from Security Analysts. This may involve adding additional conditions to the rule, whitelisting, Threshold adjustments, etc. This is what makes the rule better and efficient in achieving the “INTENT”. This is typically based like a “Waterfall Model” where you keep going back to the rule again and again to tune it according to the exact needs.

Finally, Rule Refresh Phase is another phase I would like to add in the mix. This is a stage where the Rules you put in place may no longer be applicable, or may have become obsolete and have to be replaced by better rules. Periodic clean up of old/obsolete rules is also one of the best practices in the world of SIEM Rules.

Indeed Rules Rule init??

 

 [pdf]Save as PDF[/pdf]

Log Management, Security Learning

Oracle: You have the sight now Neo!!!

Gallery 7 Comments

The objective of this post (The Matrix Quote in the title not withstanding) is to help the Database and the Security Team to enable log collection, processing and monitoring of Security Events of Interest with regards to a Business Critical Application Database. I have posted some articles on Overall Log Collection/Log Management here and here.
The key thing to note about DB Log Management is that the log is Non-Syslog Standard and has to have a DB connector/collector/agent/parser to collect, format and process the data in the DB for Auditing and Security Correlation purposes. Several SIEM solutions have the ability to pull audit data collected by Oracle DB regarding “Exactly at What Time, What User was responsible for executing What commands on the database”.

ORACLE AUDITING:
There are many different Oracle Audit facilities available for configuration:

  • Oracle audit
  • System triggers
  • Update, delete, and insert triggers
  • Fine-grained audit
  • System logs

The best method to use is the Oracle Audit Facility with the “db_extended” option to capture Command History.
This will help in tracking the exact commands executed by the attacker. This will help in the Forensic Investigation of the attacks. Events like, privilege misuse, elevation of privilege attacks, SQL Injection, Brute Force etc can be prevented with proactive monitoring, alerting and response capabilities.

REQUIREMENTS:

  1. Create a Unique Tablespace for the Audit Table: The first process is to create a separate tablespace just for auditing. The Oracle audit table is stored in “sys” table space. Because Oracle generates a lot of audit messages, this fills up the audit table, which can cause the database to crash with over flow. To avoid this problem, we must move the Oracle audit table into its own table space with its own data files separate from the core Oracle tables.
  2. Enable Auditing on the Oracle Database The auditing can be enabled either for the entire DB or for specific Tables. Please refer to the Diagram below showing the Typical Auditing Options recommended. For business critical applications, we recommend auditing SELECTS, UPDATES, and INSERTS to critical tables, such as salary info, credit card info, patient info, financial data, intellectual property, and so on.

For High Performance Databases where auditing cannot be enabled on all the tables, we can configure the “user.table_name” with the name of the table for which we would want to enable auditing for that action (as shown highlighted in yellow in the figure). We can also configure “user_name” with the names of users whose specific actions we want to audit (as shown highlighted in yellow in the figure).

AUDIT REQUIREMENTS:
Below is a table showing the some sample requirements for Database Auditing. This is just indicative and may vary from environment to environment depending on the Business Needs of your organization.

AUDIT_OPTION                      SUCCESS    FAILURE
GRANT PROCEDURE BY ACCESS BY ACCESS
SYSTEM GRANT BY ACCESS BY ACCESS
ALTER SEQUENCE BY ACCESS BY ACCESS
GRANT TABLE BY ACCESS BY ACCESS
ALTER TABLE BY ACCESS BY ACCESS
TRIGGER BY ACCESS BY ACCESS
PROCEDURE BY ACCESS BY ACCESS
ROLE BY ACCESS BY ACCESS
PUBLIC DATABASE LINK BY ACCESS BY ACCESS
DATABASE LINK BY ACCESS BY ACCESS
SEQUENCE BY ACCESS BY ACCESS
VIEW BY ACCESS BY ACCESS
PUBLIC SYNONYM BY ACCESS BY ACCESS
SYNONYM BY ACCESS BY ACCESS
ALTER USER BY ACCESS BY ACCESS
TYPE BY ACCESS BY ACCESS
USER BY ACCESS BY ACCESS
TABLE BY ACCESS BY ACCESS
CREATE SESSION BY ACCESS BY ACCESS

HOUSEKEEPING:

Audit Logging in the Oracle Database will cost Disk/Database space. This data can be purged over a regular schedule to keep the audit table clutter free and performing faster. Since the Audit data is being collected into a SIEM solution, retention should not be done at DB and instead at the SIEM.

In order to perform the housekeeping, the recommendation is as follows:
1. Create a Truncate Procedure

Create or replace procedure clean_audit is
Begin
— select sysdate from dual;
EXECUTE IMMEDIATE ‘truncate table aud$’;
commit;
End;

2. Schedule the Truncate Procedure

delete from dba_jobs where substr(what,1,6)=’CLEAN_’;
commit;
— it only need to run one time.
DECLARE
jobno number;
BEGIN    DBMS_JOB.SUBMIT (
job => jobno,
what => ‘CLEAN_AUDIT;’,
next_date => trunc(SYSDATE+1)+2/24,
interval => ‘/*2:00AM*/ trunc(SYSDATE+1)+2/24’
);
COMMIT;
DBMS_OUTPUT.PUT_LINE( ‘Job number ‘||jobno||’ setup.’ );
END;

Now that you have covered Auditing for all User Connections to the Database, you would think that you have all your bases covered. But Oracle is always coming up with surprises you see. The surprise is that you are still vulnerable to Insider Attacks because SYS, SYSDBA activities are not tracked in the Database Auditing covered above.
Gotcha!!!
—
I know, I know. No system is perfect and every system has a GAP that can be exploited. Monitoring SYS and SYSDBA is very important because, a disgruntled user can go ahead and tamper your DB and even though you are collecting DB Audit logs, you would never come to know of it. So what do we do now?
Auditing SYS, SYSDBA Activity is not straightforward as User Activity Auditing. This is because SYS and SYSDBA events are logged only at the OS level.— This is where the problems increase manifold. Let us look at it in detail –
Problem 1: The Files are stored in Oracle Installation directory thereby easily accessible and are also from a permission wise owned under Oracle Install User Group so it can be easily tampered with by any user in the Oracle Install group.
Problem 2: We will have to monitor the Client machine also to track who is the User who logged into the OS in order to login as SYSDBA and SYS.
Problem 3: If you have disabled direct client login as SYS and SYSDBA, the only way would be to login to the DB machine itself and then login as SYS and SYSDBA. In this case, you will have to track the Machine login as well as DB login.
So, unless and until you address the problems identified above, DB Audit Tracking for Log Investigation and Incident Detection will not be complete. Once again, go through the articles on Overall Log Collection/Log Management here and here to get an idea of how you can solve the problems.
Oracle: You have the sight now Neo!!!

 [pdf]Save as PDF[/pdf]