Quote of the week: “I’ve seen a number of costly incidents here in Ireland. Last one was €19,000 on a VOIP system” – Brian Honan
Feedback and/or contributions to make this better are appreciated and welcome. Just to let you know that you can have a look at:
– The full security news for this week (Divided in categories, There is a category index at the top): The categories this week include (please click to go directly to what you care about): Hacking Incidents / Cybercrime, Online Services Vulnerabilities, Unpatched Vulnerabilities, Software Updates, Business Case for Security, Web Technologies, Network Security, Database Security, Cloud Security, Mobile Security, Privacy, Tools, General, Funny
Highlighted news items of the week (No categories):
Not patched: Adobe: hole closed, hole open, Back door exploit for Android phones, Insecure Handling of URL Schemes in Appleʼs iOS, Android bugs let attackers install malware without warning
Patched: November 2010 Microsoft Black Tuesday Summary, Google releases security update for Chrome, Apple smashes patch record with gigantic update
In most organization, now days, information assets are fundamental; hence, a lot of resources are invested in protecting them. However, today, the decisions made by the management regarding the scope of invested resources is based on partial information in a “foreign” language – the technology language. Potentially resulting with excessive investments in protecting less business critical assets and lacking of investment on business critical assets. A solution to this challenge is in the ability to “translate” between business priority and technology challenges.
Information risk analysis is a relatively new discipline, and too often, information security risk decisions fall victim to one or both of the following fundamental problems: (1) the wrong people are making the decisions due to lack of clear decision as per who in the organization needs to manage the risk, what are his responsibilities and what is expected from him, which might lead to unmet expectations and objectives, lack of executive management support, and setting priorities which doesn’t make business sense and/or (2) decisions are made based on partial information, partial understanding of the risk, and without seeing the organization as a whole which generally results in spending on the wrong things, spending too much, or not spending enough
If you’re working on a client site, in addition to obeying their rules and policies on information security here are Secure Thinking’s 10 Client Site InfoSec rules you should employ to keep yourself and your information safe and protect the client.
1. Never leave equipment unattended
Laptops, phones, disks, memory sticks etc., should be taken with you, locked away securely or, in the case of laptops, locked to something solid with a Kensington style lock if they have to be left unattended.
2. Use encryption
Encrypt laptops, external disk drives, USB sticks to protect the data on them whilst on the move. This will help to protect your data should you lose an item of equipment or it is deliberately targeted.
The chaos and confusion besetting all involved in security work due to how each participant defines popular security services doesn’t appear to be heading toward sanity any time soon (i.e. what is a pen. test to you?).
I also like the threat-centric approach, so I often add in the following questions:
What are the most important assets and why?
What threats worry the team the most?
And given the propensity of most businesses to think of security only in terms of their servers (à la Chris’ tweet), I make sure to point out what wasn’t tested:
Your business and common threat tactics:
Servers on the public Internet: tested
Application Security: minimal tests performed
Social Engineer: no tests performed
Phishing: no tests performed
Client-side: no tests performed
Wireless: no tests performed
Physical Security: no tests performed
Cloud Security highlights of the week
Like any model of IT services, the cloud introduces several security challenges specific to this paradigm of computing.
Below are my top 10 cloud-specific risks that customers should understand and address when adopting cloud services. This is a summary of the key aspects of my earlier post on the topic.
Many organizations haven’t defined an overall risk management framework within which to assess and address cloud-specific risks.
Infrastructure sharing introduces the possibility that a compromise to one component of the environment will affect its “neighbors.”
Consistently enforcing security controls is hard in a rapidly-changing environment.
In an outsourced hosting arrangement, which is often part of cloud services, take some direct control over IT away from the customer.
The hypervisor, which handles virtualization of cloud IT resources, may be exploited.
It may be possible to infer information about one virtual machine by observing the state of the shared system from another aspect of the underlying system and could even lead to code execution.
The cloud service provider might incorrectly configure the hypervisor and the associated tools, introducing a vulnerability into the environment.
The organization making use of cloud services will not know how to create a governance, risk and compliance (GRC) program that applies to the cloud environment.
Critical security and GRC tasks might not get done, because each party will assume that the other needs is responsible for them.
It may be hard define, validate and enforce security and related IT controls because inner-workings of cloud services may not be visible to the customer.
Secure Network Administration highlights of the week (please remember this and more news related to this category can be found here: Network Security):
Last week my company decided to upgrade our data network bandwidth of 1 GB to 10 GB. The last time we update the design, we found that the bandwidth of the 45 vlan more secure servers, taking into account that each uplink has the 1 GB limit, we gave as 2.8 Gbps total consumption, so we chose a FWSM blade inside a Catalyst 6513. Please look the following diagram:
Freebie apps can save you money, but deployment may not be so free
Over the past few years, companies have increasingly adopted considerably stronger password policies. Unfortunately, there’s still ample confusion in how to strengthen password policies and to mitigate password-focused attacks. I found dozens of mistakes in various security portals’ password-hacking whitepapers, seen respected security vendors recommending incorrect mitigations to conflated attacks, and took note of highly knowledgeable security teams operating on mistaken assumptions.
I understand the confusion: There are many different types of password attacks (and defenses) and so much incorrect information on the Internet. The following are a few myths about password security that often surprise even the most seasoned security admins.
How often should you change your password? I get asked that question a lot, usually by people annoyed at their employer’s or bank’s password expiration policy: people who finally memorized their current password and are realizing they’ll have to write down their new password. How could that possibly be more secure, they want to know.
The answer depends on what the password is used for.
The downside of changing passwords is that it makes them harder to remember. And if you force people to change their passwords regularly, they’re more likely to choose easy-to-remember — and easy-to-guess — passwords than they are if they can use the same passwords for many years. So any password-changing policy needs to be chosen with that consideration in mind.
Secure Development highlights of the week (please remember this and more news related to this category can be found here: Web Technologies):
This article is a basic introduction to AppSensor, an OWASP project that’s been gaining a lot of traction recently. It’s a fairly simple concept, and one that I think (and hope) will be implemented in lots of applications in the near future. If you’d rather watch a video about AppSensor, here is a good one from Michael Coates, the project lead. Alternatively, here is a very quick video of a demo of AppSensor. So, let’s get started …
What is AppSensor and why should I care?
AppSensor is an implementation of an idea called application layer intrusion detection. The concept is very simple. While we have controls like intrusion detection at the network layer and web application firewalls at the web layer to detect attacks, these tools work outside the application where they are missing some context. We don’t currently have a good paradigm to represent attack detection and possible response inside an application, unless you completely roll your own. There is actually an implementation of this concept in ESAPI, (see the IntrusionDetector interface) and AppSensor’s implementation can be used as a drop-in replacement for the default handler provided by ESAPI, but more on that later. For now, let’s talk about why you need AppSensor.
I have to start this blog post with an apology; I should have posted these answers about a month ago! Thank you to James Robertson for reminding me about this!
Killmonster – SQL Injection
The Killmonster application has a SQL Injection vulnerability which allows users to bypass the user authentication check.
The users of this application must provide a username and password to authenticate and do this by entering their credentials into a form called login.php:
Part 2 of the firesheep series (Part 1 – understanding firesheep attack)
Here is an easy way to determine if a website is vulnerable to the Firesheep attack. (For the record, technically Firesheep is just a tool to easily exploit a website that does not send session cookies over TLS/SSL. You could perform this same attack with any number of tools.)
XSS is #1 threat in web application security. We all know it’s pretty common, from time to time we encounter a website where a single input field is vulnerable. Happily we send out alert(document.cookie) only to find out that session cookie is httpOnly (it’s a good sign!). On the other side we know that XSS gives us, white hats, an almost unlimited potential on how to alter the vulnerable page. We can:
steal user’s form values
redirect to form a phishing attack
look at cookies
try to send malware through a drive-by download attack
and many more…
The next major revamp to hit the Web, HTML5, promises to make the Web more powerful and flexible for the sites that adopt it. So flexible, in fact, that hackers like Lavakumar Kuppan are already hard at work demonstrating how the bad guys can twist it into new malicious uses.
In a talk he plans to give at the Black Hat security conference in Abu Dhabi next week, Kuppan will show how HTML5 allows hackers to invisibly take over users’ browsers to send spam, launch a distributed cyberattack, or even contribute their computer’s processing power to the large-scale computing task of cracking a victim’s password.
Finally, I leave you with the secure development featured article of the week courtesy of OWASP (Development Guide Series):
Understanding Enterprise Security API (ESAPI) Design Patterns
As started earlier, ESAPI is a set of security control interfaces. They are available in most major computer languages, and can be extended as singleton, extended singleton and factory patterns.
There is a download for most purposes, including:
- Java 1.4.4
- Java 2.0 rc6
- Classic ASP
- ColdFusion & CFML
Review the Organization of ESAPI Patterns
The standard interfaces are in the ESAPI SRC folder. The ESAPI object creates safe access to all interfaces. Review the default behaviors of each. There is sample code for each interface to facilitate this process.
Map the ESAPI patterns to your business and security functions. By using tested patterns, you will save time and expense, and avoid needless bugs which inevitably compromise your application.
Have a great weekend.