Three Sources to Help You Understand Cybercrime

Posted on by
5

Cybercrime is a growing threat. I thought I would take a few moments and point you to three recent news articles that discuss U.S. Government views on just how information security is proceeding, how we are doing, and how we should think about the future of infosec. They are all three interesting points of view and represent a wide variety of data seen at high levels:

 
 
 
 
These three links are interesting perspectives on how infosec is changing from a focus on compliance and prevention techniques to fully embracing the need for cross-platform, security-focused initiatives. In addition, more emphasis is on threats and risk while balancing prevention, detection capability, and effective responses when things go wrong.
 
Long term, this change is an important one if we are to protect ourselves and the data of our customers in the future. Cybercrime won’t go away, but if we can approach security with proactive strategies, we may minimize its effectiveness. 

MSI Strategy & Tactics Talk Ep. 27: The 2012 Verizon Data Breach Investigations Report

Posted on by
2

The 2012 Verizon Data Breach Investigations Report is out!  In this episode of MSI Strategy & Tactics, Adam, Phil, and John discuss the newest report’s discoveries and some of the more interesting discoveries.  Discussion questions include:

1. What was the most surprising finding?
2. What is different from the past, any trends?

Listen in and let us know what you think!

Resource:

The Verizon Data Breach Investigations Report

Panelists:

Adam Hostetler, Network Engineer, Security Analyst
Phil Grimes, Security Analyst
John Davis, Risk Management Engineer
Mary Rose Maguire, Marketing Communication Specialist and moderator
 

Click the embedded player to listen. Or click this link to access downloads. Stay safe!

Mobile Apps Shouldn’t Roll Their Own Security

Posted on by
1

An interesting problem is occurring in the mobile development space. Many of the applications being designed are being done so by scrappy, product oriented developers. This is not a bad thing for innovation (in fact just the opposite), but it can be a bad thing for safety, privacy and security.

Right now, we are hearing from several cross platform mobile developers that the API sets across iOS, Android and others are so complex, that they are often skipping some of the APIs and rolling their own code methods for doing some of this work. For example, take crypto from a set of data on the device. In many cases, rather than using standard peer-reviewed routines and leveraging the strength of the OS and its controls, they are saying the job is too complex for them to manage across platforms so they’ll embed their own code routines for doing what they feel is basic in-app crypto. 

Problems (like those with the password vault applications), are likely to emerge from this approach toward mobile apps. There is a reason crypto controls require peer review. They are difficult and often complex mechanisms where mistakes in the logic or data flows can have huge impacts on the security of the data. We learned these lessons long ago. Home-rolled crypto and other common security routines were a big problem in the desktop days and still remain so for many web applications, as well. Sadly, it looks like we might be learning those lessons again at the mobile application development layer as well.
 
Basically, the bottom line is this; if you are coding a mobile application, or buying one to access critical data for your organization, make sure the developers use the API code for privacy, trust and security functions. Stay away from mobile apps where “roll your own/proprietary security code” is in use. The likelihood of getting it right is a LOT less than using the APIs, methods and code that the mobile OS vendors have made accessible. It’s likely that the OS vendors are using peer-reviewed, strongly tested code. Sadly, we can’t say that for all of the mobile app developer code we have seen.
 
As always, thanks for reading and stay safe out there!

Disagreement on Password Vault Software Findings

Posted on by
1

Recently, some researchers have been working on comparing password vault software products and have justifiably found some issues. However, many of the vendors are quickly moving to remediate the identified issues, many of which were simply improper use of proprietary cryptography schemes.

I agree that proprietary crypto is a bad thing, but I find fault with articles such as this one where the researchers suggest that using the built in iOS functions are safer than using a password vault tool.

Regardless of OS, platform or device, I fail to see how depending on simple OS embedded tools versus OS embedded tools, plus the additional layers of whatever mechanisms a password vault adds, reduces risk to the user. It would seem that the additional layers of control (regardless of their specific vulnerability to nuanced attacks against each control surface), would still add overall security for the user and complexity for the attacker to manage in a compromise.
 
I would love to see a model on this scenario where the additional controls reduce the overall security of the data. I could be wrong (it happens), but in the models I have run, they all point to the idea that even a flawed password vault wrapped in the OS controls are stronger and safer than the bare OS controls alone.
 
In the meantime, while the vendors work on patching their password vaults and embracing common crypto mechanisms, I’ll continue to use my password vault as is, wrapped in the additional layers of OS controls and added detection mechanisms my systems enjoy. I would suggest you and your organization’s users continue to do the same.

Information Security Is More Than Prevention

Posted on by
1

 

 

 

 

 

 

One of the biggest signs that an organization’s information security program is immature is when they have an obsessive focus on prevention and they equate it specifically with security.

The big signs of this issue are knee-jerk reactions to vulnerabilities, a never-ending set of emergency patching situations and continual fire-fighting mode of reactions to “incidents”. The security team (or usually the IT team) is overworked, under-communicates, is highly stressed, and lacks both resources and tools to adequately mature the process. Rarely does the security folks actually LIKE this environment, since it feeds their inner super hero complex.

However, time and time again, organizations that balance prevention efforts with rational detection and practiced, effective response programs perform better against today’s threats. Evidence from vendor reports like Verizon DBIR/Ponemon, law enforcement data, DHS studies, etc. have all supported that balanced program work much better. The current state of the threat easily demonstrates that you can’t prevent everything. Accidents and incidents do happen. 
 
When bad things do come knocking, no matter how much you have patched and scanned, it’s the preparation you have done that matters. It’s whether or not you have additional controls like enclaving in place. Do you have visibility at various layers for detection in depth? Does your team know how to investigate, isolate and mitigate the threats? Will they do so in a timely manner that reduces the impact of the attacker or will they panic, knee-jerk their way through the process, often stumbling and leaving behind footholds of the attacker?
 
How you perform in the future is largely up to you and your team. Raise your vision, embrace a balanced approach to security and step back from fighting fires. It’s a much nicer view from here. 

Secure Networks: Remember the DMZ in 2012

Posted on by
1

Just a quick post to readers to make sure that everyone (and I mean everyone), who reads this blog should be using a DMZ, enclaved, network segmentation approach for any and all Internet exposed systems today. This has been true for several years, if not a decade. Just this week, I have talked to two companies who have been hit by malicious activity that compromised a web application and gave the attacker complete control over a box sitting INSIDE their primary business network with essentially unfettered access to the environment.

Folks, within IT network design, DMZ architectures are not just for best practices and regulatory requirements, but an essential survival tool for IT systems. Punching a hole from the Internet to your primary IT environment is not smart, safe, or in many cases, legal.
 
Today, enclaving the internal network is becoming best practice to secure networks. Enclaving/DMZ segmentation of Internet exposed systems is simply assumed. So, take an hour, review your perimeter, and if you find internally exposed systems — make a plan and execute it. In the meantime, I’d investigate those systems as if they were compromised, regardless of what you have seen from them. At least check them over with a cursory review and get them out of the business network ASAP.
 
This should go without saying, but this especially applies to folks that have SCADA systems and critical infrastructure architectures.
 
If you have any questions regarding how you can maintain secure networks with enclaving and network segmentation, let us know. We’d love to help!

10 Ways to Handle Insider Threats

Posted on by
6

 

 

 

 

 

 

As the economic crisis continues, the possibility of an insider threat occurring within a company increases. Close to 50% of all companies have been hit by insider attacks, according to a recent study by Carnegie Mellon’s CERT Insider Threat Center. (Click here to access the page that has the PDF download, “Insider Threat Study.”)

It doesn’t help when companies are restructuring and handing out pink slips. The result of leaner departments means that often there are less employees to notice when someone is doing something wrong. Tough economic times may also make it tempting for an employee to switch his ‘white hat’ to a black one for financial gain. Insider threats include employees, contractors, auditors, and anyone who has authorized access to an organization’s computers. How can you minimize the risk? Here are a few tips:

1. Monitor and enforce security policies. Update the controls and oversee implementation.

2. Initiate employee awareness programs. Educate the staff about security awareness and the possibility of them being coerced into malicious activities.

3. Start paying attention to new hires. Keep an eye out for repeated violations that may be laying the groundwork for more serious criminal activity.

4. Work with human resources to monitor negative employee issues. Most insider IT sabotage attacks occur following a termination.

5. Carefully distribute resources. Only give employees what they need to do their jobs.

6. If your organization develops software, monitor the process. Pay attention to the service providers and vendors.

7. Approach privileged users with extra care. Use the two-man rule for critical projects. Those who know technology are more likely to use technological means for revenge if they perceive they’ve been wronged.

8. Monitor employees’ online activity, especially around the time an employee is terminated. There is a good chance the employee isn’t satisfied and may be tempted to engage in an attack.

9. Go deep in your defense plan to counter remote attacks. If employees know they are being monitored, there is a good possibility an unhappy worker will use remote control to gain access.

10. Deactivate computer access once the employee is terminated. This will immediately end any malicious activity such as copying files or sabotaging the network.

Be vigilant with your security backup plan. There is no approach that will guarantee a complete defense against insider attacks, but if you continue to practice secure backup, you can decrease the damage. Stay safe!

MSI Strategy & Tactics Talk Ep. 26: Hacking Back or Strikeback Technologies

Posted on by
2

Hacking back or strikeback technologies is a system  engineering term that could occur in a situation with a positive loop, whereby each component responds with an increased reaction to the response of the other component, and so the problem gets worse and worse. (The Information Security Dictionary: Defining the Terms That Define Security, by Urs E. Gattiker) Recently, a honey pot was created with some strikeback technology in the code.  In this episode of MSI Strategy & Tactics, Brent Huston and the techs discuss the various aspects of this technology and how it would affect you.  Discussion questions include:

  1. What is the history of strike back, hacking back and how does it apply to today when you have major teams working to take down bot nets and such?
  2. HoneyPoint has a type of technology called “defensive fuzzing” which does something that has been compared to strikeback. How it is different than other technologies?
  3. What is the current take on the legality of strikeback/hacking back? Are organizations being put at risk if they attack their attackers or if their security teams go on offense?
Panelists:
Brent Huston, CEO and Security Evangelist
Adam Hostetler, Network Engineer, Security Analyst
Phil Grimes, Security Analyst
John Davis, Risk Management Engineer
Mary Rose Maguire, Marketing Communication Specialist and moderator
 

Click the embedded player to listen. Or click this link to access downloads. Stay safe!

Threat and Vulnerability: Pay Attention to MS12-020

Posted on by
5

Microsoft today released details and a patch for the MS12-020 vulnerability. This is a remotely exploitable vulnerability in most current Windows platforms that are running Terminal Server/RDP. Many organizations use this service remotely across the Internet, via a VPN, or locally for internal tasks. It is a common, prevalent technology, and thus the target pool for attacks is likely to make this a significant issue in the near future. 

 
Please identify your exposures to this vulnerability. Exploits are likely currently being developed. We have not yet (3/13/12 – 2.15pm Eastern) seen exploitation or an increase in probes for port 3389, but both are expected to occur shortly.
 
Please let us know if you have any questions or if we may be of any assistance with this issue.
 
UPDATE: 
 
 
This article makes reference to a potential worm attack vector, which we see as increasingly likely. Our team believes the exploitation development time to be significantly less than 30 days and more like 1-3 days for resourced attackers. As such, PLEASE TREAT THIS AS A SIGNIFICANT INTERNAL VULNERABILITY as well. Certainly, IMMEDIATE consideration is needed for Internet exposed systems, but INTERNAL systems should be patched as soon as manageable as well.
 
UPDATE II:
 
 
This confirms the scope and criticality of this issue.
 
UPDATE III:
 
Just a quick note – we are seeing vast work on the MS12-020 exploit. Some evidence points to 2 working versions. Not public, yet, but PATCH NOW. Internal & protected networks too.
 
UPDATE IV:
 
MSI is proud to announce the immediate availability of a FREE version of HoneyPoint, called HPRDP2012 to help organizations monitor for ongoing scans and potential future worm activity. The application listens on port 3389/TCP and is available for OS X (Intel), Windows & Linux. This application is similar to our releases for Conficker & Morto, in that it will be operational for a set time (specifically until October 1, 2012). Simply unzip the application to where you would like to run and execute it. We hope this helps organizations manage this vulnerability and detect impacts should scans, probes or a worm emerge. Traditional HoneyPoint customers can use Agent and/or Wasp to listen for these connections and report them centrally by dilating TCP listener HoneyPoints on port 3389. Please let us know if you have any questions.
 
 
 
 
 

4 Tips for Teaching Your Staff About Social Engineering

Posted on by
4

If there is one thing that is tough to prevent, it is a person whose curiosity overrides their better judgement. Human nature leans toward discovery. If someone believes a valuable piece of information is available, there’s a very good chance she will satisfy her curiosity.

Social engineering, the process of obtaining confidential information through tricking people to do things they should not do; is on the rise. So how can you help your staff recognize social engineering before it’s too late?

Here are a few tips:

1. Create a process for validating outside inquiries.

Often, an attacker has done their homework in obtaining certain pieces of information such as having another employee’s name or their calendar to establish credibility. Create a process for inquiries, making someone the gatekeeper for such calls. Tell staff to not give out confidential information before checking with the gatekeeper.

2. Secure access into the organization.

Does your organization have guards? If not, it is the job of every employee to be alert to outsiders.

Name badges are another way to do this and require everyone to keep it visible. Explain to staff that it is perfectly legitimate to say, “I’m sorry, who did you say you were with again?” Teach awareness through fun exercises and safety posters.

3. Train staff to resist picking up strange USB keys.

This is difficult because it is where a person’s curiosity can get the best of them. However, a person has no idea what is on a found USB key. Would they eat food left on the floor of the kitchen? (Some, unfortunately, might!) Why would anyone take a found USB key and plug it into their computer? Curiosity. Create an incentive program for employees to return found keys to an IT administrator.

4. Fine tune a sense of good customer service.

Most people are helpful. This helpful nature is especially nurtured by organizations who want to provide good customer service to both internal staff and external contacts. Attackers take advantage of this by insisting that it would “be very helpful” if they could get someone’s confidential information in order to do their job. Train your staff to stick to the plan of verifying all inquiries by going through the proper channels. Help employees understand that this approach is truly the most “helpful” since they’ll be saving the company countless dollars if it’s an attack.

Consistent awareness is the key to resisting social engineering attacks. Use these tips and decrease your probability of an attack. Stay safe!