Wednesday, April 15, 2015

“Cyber Threat Intelligence” What Is Needed For Identification and Response?

“Cyber Threat Intelligence”
What Is Needed For Identification and Response?

What is cyber threat intelligence?
CTI “Cyber Threat Intelligence “is a term used to address any information which can be used to protect your organization IT assets against an attacker.

This IT (Threat Intelligence) can be of many forms like internet bases IP addresses, Attacker geolocations TTP’s (Tools , Tactics and Procedures ), which would work as an indicator OR early warnings of attacks or an attempt to harm the IT Infrastructure in turn harming business.

There are number vendors on the globe who give TI feeds which can be integrated with your security controls like SIEM, GRC tool and other correlation engines.

This is an attempt to identify the information which is needed as actionable TI which can used to defend your organization.

1.       Drivers
a.       These are conditions of the attacks like a Zero Day, Business related breaking news/ announcements for the organization.
2.       Prerequisites
a.       What would the attacker need to generate and trigger an attack on your organization e.g.:  Type of security controls on your perimeter, network and endpoints. Type of devices (endpoints, internet facing web servers, routers firewalls etc.  ) which are exposed to the internet.   
3.       Capabilities
a.       Capabilities of the attacker and the attack itself e.g.: The script Kidde’s would be able to generate an attacks but then would not possess the capability of post attack activity. OR a professional attacker would have the capabilities of generating an attack but the defense mechanism would be able to partially stop the attack where the attack would not get the attacker the intended results.  
4.       Components
a.       Attacking component TTP’s (Tools, Tactics and Procedures) which are used in past attacks conducted by the attacker. This would help us with indicators for defending the attack.
5.       Measurement
a.       This component is important as the measurement of the attack in terms of number and type of security events generated pre- attack condition.
6.       What is the threat?
a.       Measurements the threat of the past attack would help us in mapping the threat findings with our organization
7.       What are the threat vectors,
a.       These vectors would be more of a “type of attacks” which would be seen in the attack phase.
8.       Where else the threat vector seen on the globe?
a.       Historical threat vectors used by the attacker in past should be a part of the TI information.
9.       What was the threat impact?
a.       Historical threat impact on the victims would help to measure the attackers TTP’s
10.   What were the parameters of compromise?
a.       What would be the needed condition and parameters for a successful compromise to be conducted? 
11.   What could be the early warnings?
a.       Early warnings and indicators of past attacks conducted by the attacker.
12.   What would be a practical and approachable defense mechanism?  
a.       Historical data in terms of approach taken by the defender to defend the attacks.
13.   What would be the business impact?
a.       What was the business impact on victims in terms of data theft, ransomware and business dis-continuity  
14.   What type of IT for Zero Days?
a.       What information would the TI share in terms of Zero Days in terms of IP addresses, Geolocations, Domains names, ISP information, file names, MD5 hashes etc.?
15.   Pattern of attacks in past
a.       What patterns where generated by the attackers OR what type of internet traffic (Inbound/Outbound) per-attack conditions
16.   Attack timelines before a successful compromise.
a.       These timelines would help us to understand the skills of the attacker and allow us the decide max time frame to respond against a business accepted condition of a known vulnerability
17.   Zero Day detection and patterns based on packet, ports and geolocations.
a.       What type of traffic patterns are generated in case of Zero Days for a pre-compromise conditions
18.   What and how security controls where bypassed?
a.       The historical data of the TTP’s for bypassing of the security controls is very important as this would give us pinpointed information which would help us to defend such attacks.
19.   Post compromise (Forensics Investigation) information.               
a.       Post compromise information like...
                                                               i.      File names
                                                             ii.      MD5 hashes    
                                                            iii.      Inbound and Outbound Traffic
                                                           iv.      Internal traffic patterns
                                                             v.      Detection by internal security controls
                                                           vi.      Auto-defense OR events generated by security controls
                                                          vii.      OS and application level errors generated by the attack vector

The above are few indicators which a TI tool vendor should provide. I strongly believe that if the above information is provided by the vendors, we can surely respond and try to defend attacks.

Comments and inputs are most welcome.   

Friday, June 27, 2014

StealthWalker The Swiss army knife of privacy application

StealthWalker The Swiss army knife of privacy version 2.5.3 released. It is more stable you also have a global system key to renew TOR IP. Get your full functional copy today :)

Wednesday, December 18, 2013

Cyber Threat Protection for Executives to be Included in 2014 Business Plans

Most high profile executives can be easier targets as they are usually absent from routine security training which now exists in most firms. Over 80% of breaches or threats result from common sense security protocols not being implemented by the executive or his/her immediate staff.

These can include:
  • Not doing routine upgrades on personal machines
  • Accepting or using random memory drives
  • Not having apps verified by IT/security departments before installing on phones, tablets or computers
  • Leaving an office unlocked or making it accessible
  • Taking sensitive work home
  • Using generic email addresses (gmail, hotmail etc) for work
  • Not having the latest anti-virus or internet security software installed
  • Giving low level IT staff access to Super Admin on company servers
  • Not having a security filter installed on company emails
  • Lack of proactive cyber scanning for threat chatter or discussion relating to the executive
  • Using unverified cloud backup services
  • Not using a shredder (old school trash digging is still done by serious adversaries)
  • Using public wifi
  • Never changing passwords or using passwords which are weak
  • Not doing due diligence on vendors and giving them access
  • Randomly clicking links on “alarming emails” or alerts (designed to make you click)
(This is by no means a complete list)

Wednesday, October 16, 2013

Things You Should Never Assume When it Comes to Network Security

Things You Should Never Assume When it Comes to Network Security

  • The security systems we have are good enough.
  • Our security architecture is so complex no attacker will be able to get into our network.
  • We only REALLY need to worry about inbound firewall policies. The danger is out there! (not in the network).
  • We're up to date on patching our vulnerabilities so we are in the clear.
  • The firewall configuration is secure because it’s managed by an outside firm.
  • If no one is screaming about an outage or a virus then everything is hunky dory.
  • Network operations and application owners understand security.
  • Security is more important than business operations.
  • The security processes we have are good enough – they are written down on paper.
  • Employees will follow most if not all of the security policies.
  • It’s much more secure if we virtualize it.

Thursday, August 29, 2013

17 Security Related Phrases We Are Sick of Hearing...

  1. “What is the key to our wireless again?”
  2. “I downloaded something and now my computer is acting all weird”
  3. “Why do I need to use the VPN all the time?”
  4. “How come I have to apply updates all the time?”
  5. “At home I run macs because they don’t get viruses and malware”
  6. “Hey, can you teach me how to hack?”
  7. “Is there any way to get around me having to type my password over and over again?”
  8. “I clicked on it because it totally looked like it was from my bank”
  9. ”Should I get my CISSP?”
  10. “Is it safe to click on this self-signed cert?”
  11. “I have no idea how that pornography got on my computer?”
  12.  “The webpage said that this cloud services was 100% secure?”
  13. “I locked myself out of my account again, can you reset it?”
  14.  “I think I may have just lost a bunch of important files, what do I do?”
  15. “Can I get root access on this server?”
  16. “We will get back to you on those security-related changes you recommend”

Wednesday, May 15, 2013

3 Big Mistakes In Incident Responce - Must Read

Saturday, April 20, 2013

8 tips for a security incident handling plan

8 tips for a security incident handling plan

Incident handling is a vast topic, but here are a few tips for you to consider in your incident response

1.    Have an incident response plan. It is, of course, the most obvious advice, however you would be amazed at the number of organisations that "haven't quite got around to it yet".
It doesn't need to be 400 pages long (nor should it be half a page most likely) but documenting your incident response plan and distributing it up front can make a massive difference when the inevitable occurs.
2.    Pre-define your incident response team and make sure it draws from multiple disciplines. A good incident response team should not just consist of IT or security people (though they undoubtedly need to be a strong core), but should also include PR, HR, Legal and executives to name just a few.

Team people. Image from Shutterstock 

For instance, not involving the PR team could result in external communications that are more damaging than the breach in the first place.
Make sure each member of the team is briefed on their involvement and expectations. Watch that list of team members, however. It gets old quickly as people leave, go on vacation or just forget what they signed up for.
3.    Define your approach: watch and learn or contain and recover. We have seen great examples of this in the news recently. When an incident occurs and is verified - for instance a hacker compromising one of your web servers - you need to make the call on whether to recover as quickly as possible or to watch the attacker and learn.
You need to make this policy decision upfront because it requires good preparation, executive support and a skilled team to manage the risk. Most organisations will (and should) focus on containing the damage and recovering business systems.
Detailed forensics and observing the attackers is often too great a business expense for many firms, but don't give up entirely on capturing evidence - you never know when you may need it later.
If you are a target likely to come under persistent long term attacks from adversaries (perhaps a nation state, a competitor or a hacking gang that you have riled somehow) learning more about your adversary to help build future defences can make a lot of sense.
You should not venture down this path unless you have the resources (people, duplicate systems, network infrastructure for suitable containment) to execute it successfully and it absolutely requires executive buy-in or you will find yourself out of a job very quickly if it goes wrong.
Make this decision up front, discuss the risk attitude of the business and alter your incident response process appropriately. Of course, you won't watch and learn on every attack, so identify the two paths and when you will use them.
4.    Pre-distribute call cards. Another common mistake is to depend upon your normal communication infrastructure in the event of an incident.
Imagine that the LAN stops working, no-one knows anyone else's number and email doesn't work. It will be pretty tough to handle an incident in that situation.
Decide up front communication methods, choose a call bridge or similar and then distribute details to each of the stakeholders.
5.    Forensic and incident response data capture. This goes wrong a lot. During and after security incidents, pressure can be high and there is a tendency to rush, which - of course - means mistakes are made.

Magnifying glass on files. Image from Shutterstock
You need to ensure that you have comprehensively captured the right data and logs without taking up hours you don't have - it's not a trivial balance.
In particular, define how you will capture notes (I like a lined, dated paper notebook which is easy for courts to get their heads around) and evidence.
Do you run Volatility to capture memory? Do you power off the machine and take an image of the disk to capture as much as you can before the attack shuts down? Decide in which instances you will follow each path and build a toolkit ready to go.
6.    Get your users on-side. Incident response is not just an 'IT thing'. Make sure your incident response links up with your organisation's acceptable use policy and security awareness program.
You want your users to know how to tell you if they think an incident is occurring. In particular, system administrators, application owners and data owners should know how to contact you if they spot something unusual. The incident response process can then be spun up (or spun down if it's a false alarm) quickly. Don't just write the policy and leave it on the intranet somewhere.
7.    Know how to report crimes and engage law enforcement. Certain types of incident may require you to report to law enforcement but often when such an opportunity arises no-one knows exactly how to do it.
From having your web server hacked to the theft of credit card details or IP it pays to understand the process and requirements in advance. Check out Naked Security's quick guides on reporting computer crimes and find out who your representative is before you need them.
8.    Practice makes perfect. The process can be documented but when it comes time to use it the bridge is enabled and no one connects or knows what to do. Stage an incident and have your team dial in and work through the mock scenario.