Check out this article about Athena’s PathFinder from Shamus McGillicuddy, News Editor at TechTarget today:

Athena Security’s new PathFinder network path analysis product offers such visibility into security infrastructure. Network engineers can upload configuration data of firewalls, switches and routers into the tool, which generates an offline, virtual model of a network. They can then simulate packet transmission through this network model, and PathFinder predicts how device configurations and firewall rules will affect packet flows.

There’s an interesting case study of using PathFinder to troubleshoot service availability after changes to the DMZ structure in a network.

“Since we got [PathFinder] we’ve been using it to troubleshoot… how the path runs through our ASA [Cisco Adaptive Security Appliance],” he said. “For PCI we’ve recently split our DMZ into four different DMZs. When we first set it up, we didn’t have the routing exactly right through it, and our VMware guy was having some issues with some of the servers that we had in the DMZ.”

With PathFinder’s offline network path analysis features, Serauskas used his device configurations to create a model of his network and sent simulated packets through the DMZ. He saw that the ASA was intercepting certain packets as they passed through it. He examined the rules on the ASA and discovered that some entries were sending the packets through an older path that had gone unused before segmentation.

“We just had to change the path on the DMZ ­— make the proper changes on the firewall for it — and once we made the changes to the config, we ran a new test [in PathFinder],” he said. “Once we knew the IP that [the VMware admin] was trying to get through had traveled correctly, we made the change [in production].

Read the whole article.

Bruce Schneier’s blog links to an interesting article on the difference between threats and vulnerabilities.  Its a quick read and useful as a reference.

RSA is reporting today in an open letter to their customers that they have detected an extremely sophisticated attack on their systems and that some information related to their SecurID two-factor authentication systems has been extracted:

Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.

Rich Mogull over at Securosis has additional commentary.

What’s interesting is that this is no random drive-by attack, but rather a targeted assault on a major security vendor.  This is a big deal, of course, because so many organizations rely on RSA’s SecurID systems for authentication.  We currently don’t know the vector of the attaack, what information was lost, or exactly how this will affect SecurID users.  One thing is for sure, if you have a SecurID token from a bank or some other provider, you will want to contact them for guidance.

This is one evolving situation we’ll be watching over the next several days and weeks.

Shrdlu over at the Layer8 security blog has come up with a list of security metrics that will doubtless be very useful in communicating with your CISO:

• the number of times you have to beg your sysadmins to patch (per release cycle)
• the number of senior executives that violate the security policies they signed off on (per month or year)
• the number of conferences your boss refuses to send you to (per year)
• the number of security topics you discuss, divided by the number of drinks you have, at the one conference you’re allowed to attend
• the number of times you discover a homegrown “crypto” function during code reviews
• the number of times a security vendor tries to go over your head to make a sale (or at least schedule a demo)
• the number of (prohibited) iPads in your building, times the number of support requests for said iPads
• the number of times you have to explain cross-site scripting, per developer, per year (bonus if you have to explain it to a “security professional”)
• percentage of #LIGATT tweets in your tweetstream per day
• the number of times a network or application problem is blamed on “the firewall”
• number of incidents that you still aren’t sure really counted as actual incidents
• number of auditors per audit instance per year, times the number of staff members that have to interact with said auditors
• number of security-related PowerPoint slides generated per year, minus the number of recycled ones
• number of desks you’ve had to replace due to head damage, per job

Over at TechTarget, Joel Snyder writes about configuring access control lists on your routers to maintain security in the network control plane.

Do you have SNMP enabled on edge devices? Fine… so long as you also have an access list saying that those SNMP packets can only come from your management station. Is the management interface, whether HTTP, HTTPS, SSH or (heaven forbid) Telnet running?

Fine … so long as no one outside our network can ever get there.

We call this the “control plane” or “management plane.” Think of it as a different network that runs in parallel to your data network, and is used to control, monitor and manage the data network. In huge networks, there is a true network control plane that is completely separate from the data that the device sees. But in many smaller networks, control plane, management plane, and data plane run on the same wire.

You can, and should, secure your network control plane in many ways, but they mostly come down to two techniques: access control lists and self-protection.

ACCESS CONTROL LISTS MANAGE TRAFFIC TO EDGE DEVICES
Access control list protections usually occur when you put a block of some sort in non-firewall devices at the edge and core of your network. A good example is SNMP. Let’s say you have an SNMP management station at 10.20.30.161. That represents the one valid flow to and from that management station to network and security devices. Now, any other SNMP traffic floating around on your network, or coming in from the edge, should be blocked. If you have intermediate routers in your network, and certainly if you have firewalls, you should use them to block SNMP traffic — and any other management traffic — to your security and network devices, except from authorized sources.

Good advice, and an excellent example of best practices for securing your network infrastructure.  To ensure that your network infrastructure remains secure, you will want to configure and enforce access control restrictions like these on all of your non-firewall devices.  Furthermore, you will want to routinely audit the network devices to ensure that they continue to follow these best practices.  When changes are made to a device’s access control lists, you will want to be notified when changes cause the device to fail to meet these practices.

Of course, auditing all of the devices in your network infrastructure can be a huge job.  The attention to detail required to make sure you get it right and don’t miss something takes a lot of time.  It’s difficult to perform the audits frequently enough to be effective without tools and automation to facilitate the process.  Fortunately, the security checks in Athena FirePAC provide a perfect vehicle for implementing these kinds of network best practices.

For example, FirePAC provides a standard security checks for SNMP that can be customized to ensure that the device policy allows SNMP messages from only the management station and to flag the check if any the policy allows any other source.  FirePAC provides other standard checks for various management protocols that can be similarly customized to check for restrictions to allow only access from the management station.  These kinds of customizations to the standard security checks in FirePAC will help you tailor the Security Audit report to your organization’s network policy and simplify the task of ensuring the security of your network.

The Wall Street Journal is reporting today that Shiite fighters in Iraq were able to capture video feeds from U.S. Predator drones using commercially available software.

Senior defense and intelligence officials said Iranian-backed insurgents intercepted the video feeds by taking advantage of an unprotected communications link in some of the remotely flown planes’ systems. Shiite fighters in Iraq used software programs such as SkyGrabber — available for as little as $25.95 on the Internet — to regularly capture drone video feeds, according to a person familiar with reports on the matter.

[...]

The stolen video feeds also indicate that U.S. adversaries continue to find simple ways of counteracting sophisticated American military technologies.

[...]

Some of the most detailed evidence of intercepted feeds has been discovered in Iraq, but adversaries have also intercepted drone video feeds in Afghanistan, according to people briefed on the matter. These intercept techniques could be employed in other locations where the U.S. is using pilotless planes, such as Pakistan, Yemen and Somalia, they said.

[...]

The potential drone vulnerability lies in an unencrypted downlink between the unmanned craft and ground control. The U.S. government has known about the flaw since the U.S. campaign in Bosnia in the 1990s, current and former officials said. But the Pentagon assumed local adversaries wouldn’t know how to exploit it, the officials said.

Most interesting was this comment about the difficulty in upgrading the drones to encrypt the video downlink.

Officials stepped up efforts to prevent insurgents from intercepting video feeds after the July incident. The difficulty, officials said, is that adding encryption to a network that is more than a decade old involves more than placing a new piece of equipment on individual drones. Instead, many components of the network linking the drones to their operators in the U.S., Afghanistan or Pakistan have to be upgraded to handle the changes.

Security has to be built in from the start, not added in as an afterthought.  Of course, you should never underestimate your adversaries either!

A new report released today from Verizon Business, “2009 Supplemental Data Breach Investigations Report: An Anatomy of a Data Breach,” takes a look the 15 most common types of security attacks. The report is drawn from data published in the “2009 Verizon Business Data Breach Investigations Report,” issued in April. That study reviews the cybercrime cases worked by Verizon’s Investigative Response team and analyzed more than 90 forensic investigations involving some 285 million compromised records.

The report identifies and profiles the most common attacks. For each type of attack, the report provides case examples, frequency of occurrence, threat sources, warning signs, controls that can deter or prevent threats, and commonly affected industries.

The report identifies and ranks by frequency the following top 15 types of attacks:

1. Keyloggers and spyware.
2. Backdoor or Command/Control.
3. SQL injection.
4. Abuse of system access/privileges.
5. Unauthorized access via default credentials.
6. Violation of Acceptable Use and other policies.
7. Unauthorized access via weak or misconfigured ACLs.
8. Packet sniffer.
9. Unauthorized access via stolen credentials.
10. Pretexting (social engineering).
11. Authentication bypass.
12. Physical theft of asset.
13. Brute-force attack.
14. RAM scraper.
15. Phishing (and variants).

It’s interesting to observe that 6 of the 15 list proper egress filtering as one method of mitigating the attack. That’s more than a third of the most common attacks that can be stopped by proper firewall configurations. Read the whole thing.

Kelly Jackson Higgins at DarkReading writes that a pair of German researchers have developed a set of tools that automate attacks on the Multiprotocol Layer Switching (MPLS) and Ethernet networking technologies used in some enterprise network service offerings.

The tools exploit similar inherent security weaknesses in the two networking technologies — namely in how they forward traffic.

[...]

To execute an MPLS or Ethernet carrier network hack, the attacker first must get into the network, either by hacking a router or a management tool. Then Rey and Mende’s MPLS hacking tool could be used: It modifies the labels that are added to packets in an MPLS network and determine how those packets get forwarded. This lets an attacker silently redirect traffic to other sites, such as a malicious DNS server or a phony authentication server, Rey says. “The victim doesn’t notice anything and the attacker has both directions of traffic” in his control, he says. “The whole VPN model of trust is violated,” he says.

The attack doesn’t target a specific vulnerabilty — just the way MPLS operates. The story is much the same for Ethernet. VLAN-tagging, for instance, helps carriers separate different customers’ traffic across their backbones. “But there’s no encryption and no additional security” with Ethernet, Rey says. “It’s just traffic separated by adding some more bits to the traffic, which brings us back to being able to modify those bits” with our hacking tool, he says.

The researchers plan to release the tools at Black Hat Europe next week.

The NYTimes is reporting that a “vast electronic spying operation” was discovered by researchers in Toronto.  They concluded that thousands of computers in government and private offices around the world were compromised.

The researchers said that the system was being controlled from computers based almost exclusively in China, but that they could not say conclusively that the Chinese government was involved.

The researchers, who are based at the Munk Center for International Studies at the University of Toronto, had been asked by the office of the Dalai Lama, the exiled Tibetan leader whom China regularly denounces, to examine its computers for signs of malicious software, or malware.

Their sleuthing opened a window into a broader operation that, in less than two years, has infiltrated at least 1,295 computers in 103 countries, including many belonging to embassies, foreign ministries and other government offices, as well as the Dalai Lama’s Tibetan exile centers in India, Brussels, London and New York.

The researchers, who have a record of detecting computer espionage, said they believed that in addition to the spying on the Dalai Lama, the system, which they called GhostNet, was focused on the governments of South Asian and Southeast Asian countries.

[...]

The malware is remarkable both for its sweep — in computer jargon, it has not been merely “phishing” for random consumers’ information, but “whaling” for particular important targets — and for its Big Brother-style capacities. It can, for example, turn on the camera and audio-recording functions of an infected computer, enabling monitors to see and hear what goes on in a room. The investigators say they do not know if this facet has been employed.

The researchers were able to monitor the commands given to infected computers and to see the names of documents retrieved by the spies, but in most cases the contents of the stolen files have not been determined. Working with the Tibetans, however, the researchers found that specific correspondence had been stolen and that the intruders had gained control of the electronic mail server computers of the Dalai Lama’s organization.

The electronic spy game has had at least some real-world impact, they said. For example, they said, after an e-mail invitation was sent by the Dalai Lama’s office to a foreign diplomat, the Chinese government made a call to the diplomat discouraging a visit. And a woman working for a group making Internet contacts between Tibetan exiles and Chinese citizens was stopped by Chinese intelligence officers on her way back to Tibet, shown transcripts of her online conversations and warned to stop her political activities.

A separate group of researchers in the UK issued their own report, focusing on the technical nature of operation and possible countermeasures.

This event is significant for several reasons.  The scope of the operation is impressive.  It was a targeted surveillance attack for apparent political purposes intended to collect actionable intelligence by a repressive police state.  The capability of the malware to record sound and video from compromised computers poses a very real threat of illicit or covert electronic surveillance from any connected computer with a microphone and webcam.  The techniques of the attack, using socially targeted malware were highly effective.  Typical countermeasures for this type of attack involve mandatory access controls and intrusive operational security procedures, which are unlikely to be deployed outside of secure government or military organizations. Such threats are bound to proliferate into online criminal activities. The recent data breach at Heartland Payment systems involving targeted malware may indicate that this is already starting to happen.

Circle ID reports that major domain registrat Network Solutions has been expriencing a massive DDOS UDP/53 attack on their domain servers for the past 48 hours.  The Network Solutions blog confirms this: “There is a spike in DNS query volumes that is causing latency for the delay in web sites resolving. This is a result of a DDOS attack.  We are taking measures to mitigate the attack and speed up queries.”

A post on NANOG provides some additional detail:

A DOS where lots of people's dns servers around the world
are being queried with bogus sourced dns requests not from port 53 for
'NS? .'.  This then bounces back to their authoritative nameservers which
are getting traffic overload.

...

These are the result of a spoofed dns recursion attack against our servers.
The actual packets in question (the ones reaching your servers) do NOT
originate from our network as such there is no way for us to filter things
from our end.

If you are receiving queries from 76.9.31.42/76.9.16.171 neither of these
machines make legitimate outbound dns requests so an inbound filter of
packets to udp/53 from either of these two sources is perfect.

If you are receiving queries from 66.230.128.15/66.230.160.1 these servers
are authoritative nameservers. Please do not blackhole either of these IPs
as they host many domains. However, these IPs do not make outbound DNS
requests so filtering requests to your IPs from these ips with a destination
port of 53 should block any illegitimate requests.

An ACL similar to:
access-list 110 deny udp host 66.230.160.1 neq 53 any eq 53
access-list 110 deny udp host 66.230.128.15 neq 53 any eq 53
Is what you want.

This attack could potentially affect more than 7.6 million domain names.  Given the recent rapid spread of threats like the Downadup worm, I’m sure we’re going to be seeing more attacks like this in the not-too-distant future.

UPDATE: Network Solutions says DNS queries for web sites should be responding normally now.