Slashdot Mirror

An anonymous reader quotes a report from ZDNet: Security researchers are warning Linux system users of a bug in the Linux kernel version 4.9 and up that could be used to hit systems with a denial-of-service attack on networking kit. The warning comes from Carnegie Mellon University's CERT/CC, which notes that newer versions of the Linux kernel can be "forced to make very expensive calls to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for every incoming packet which can lead to a denial of service (DoS)".

It lists a number of network-equipment vendors, PC and server manufacturers, mobile vendors, and operating-system makers that may be affected but notes that it hasn't confirmed whether any of them actually are. But, given the widespread use of Linux, the bug could affect every vendor from Amazon and Apple through to Ubuntu and ZyXEL. A remote attacker could cause a DoS by sending specially modified packets within ongoing TCP sessions. But sustaining the DoS condition would mean an attacker needs to have continuous two-way TCP sessions to a reachable and open port. The bug, dubbed "SegmentSmack" by Red Hat, has "no effective workaround/mitigation besides a fixed kernel."

A recently discovered bug in many Bluetooth firmware and OS drivers could allow an attacker within about 30 meters to capture and decrypt data shared between Bluetooth-paired devices. Researchers at the Israel Institute of Technology discovered the flaw, which was flagged today by Carnegie Mellon University CERT. It affects Bluetooth's Secure Simple Pairing and Low Energy Secure Connections. ZDNet reports: As the CERT notification explains, the vulnerability is caused by some vendors' Bluetooth implementations not properly validating the cryptographic key exchange when Bluetooth devices are pairing. The flaw slipped into the Bluetooth key exchange implementation which uses the elliptic-curve Diffie-Hellman (ECDH) key exchange to establish a secure connection over an insecure channel. This may allow a nearby but remote attacker to inject a a bogus public key to determine the session key during the public-private key exchange. They could then conduct a man-in-the-middle attack and "passively intercept and decrypt all device messages, and/or forge and inject malicious messages." Thankfully, patches are on the way. "Intel recommended users upgrade to the latest support driver and to check with vendors if they have provided one in their respective updates," reports ZDNet. "Dell has released a new driver for the Qualcomm driver it uses while Lenovo's update is for the flaw in Intel software. LG and Huawei have referenced fixes for CVE-2018-5383 in their respective July updates for mobile devices." It is not yet known if Android, Google, or the Linux kernel are affected. Apple has released a patch for the flaw earlier this month.

An anonymous reader writes from a report via BleepingComputer: Last week, at the BlackHat Asia 2017 security conference, researchers from cyber-security firm Cylance disclosed two vulnerabilities in the firmware of Gigabyte BRIX small computing devices, which allow an attacker to write malicious content to the UEFI firmware. During their presentation, researchers installed a proof-of-concept UEFI ransomware, preventing the BRIX devices from booting, but researchers say the same flaws can be used to plant rootkits that allow attackers to persist malware for years. The two vulnerabilities discovered are CVE-2017-3197 and CVE-2017-3198. The first is a failure on Gigabyte's part to implement write protection for its UEFI firmware. The second vulnerability is another lapse on Gigabyte's side, who forgot to implement a system that cryptographically signs UEFI firmware files. Add to this the fact that Gigabyte uses an insecure firmware update process, which doesn't check the validity of downloaded files using a checksum and uses HTTP instead of HTTPS. A CERT vulnerability note was published to warn users of the impending danger and the bugs' ease of exploitation.

Orome1 quotes a report from Help Net Security: A zero-day bug affecting Windows 10, 8.1, Windows Server 2012 and 2016 can be exploited to crash a vulnerable system and possibly even to compromise it. It is a memory corruption bug in the handling of SMB traffic that could be easily exploited by forcing a Windows system to connect to a malicious SMB share. Tricking a user to connect to such a server should be an easy feat if clever social engineering is employed. The vulnerability was discovered by a researcher that goes by PythonResponder on Twitter, and who published proof-of-exploit code for it on GitHub on Wednesday. The researcher says that he shared knowledge of the flaw with Microsoft, and claims that "they had a patch ready 3 months ago but decided to push it back." Supposedly, the patch will be released next Tuesday. The PoC exploit has been tested by SANS ISC CTO Johannes Ullrich, and works on a fully patched Windows 10. "To be vulnerable, a client needs to support SMBv3, which was introduced in Windows 8 for clients and Windows 2012 on servers," he noted, and added that "it isn't clear if this is exploitable beyond a denial of service." Until a patch is released, administrators can prevent it from being exploited by blocking outbound SMB connections (TCP ports 139 and 445, UDP ports 137 and 138) from the local network to the WAN, as advised by CERT/CC. "The tweet originally announcing this issue stated that Windows 2012 and 2016 is vulnerable," the researcher said. "I tested it with a fully patched Windows 10, and it got an immediate blue screen of death."

mask.of.sanity writes: A researcher has reported 10 vulnerabilities in McAfee's VirusScan Enterprise for Linux that when chained together result in root remote code execution. McAfee took six months to fix the bugs issuing a patch December 9th.
Citing the security note, CSO adds that "one of the issues affects Virus Scan Enterprise for Windows version 8.7i through at least 8.8." The vulnerability was reported by Andrew Fasano at MIT's federally-funded security lab, who said he targeted McAfee's client because "it runs as root, it claims to make your machine more secure, it's not particularly popular, and it looks like it hasn't been updated in a long time."

The Department of Homeland Security's CERT issued a warning last week that users should "strongly consider" not using some models of NetGear routers, and the list expanded this week to include 11 different models. Netgear's now updated their web page, announcing eight "beta" fixes, along with three more "production" fixes. chicksdaddy writes: The company said the new [beta] firmware has not been fully tested and "might not work for all users." The company offered it as a "temporary solution" to address the security hole. "Netgear is working on a production firmware version that fixes this command injection vulnerability and will release it as quickly as possible," the company said in a post to its online knowledgebase early Tuesday.

The move follows publication of a warning from experts at Carnegie Mellon on December 9 detailing a serious "arbitrary command injection" vulnerability in the latest version of firmware used by a number of Netgear wireless routers. The security hole could allow a remote attacker to take control of the router by convincing a user to visit a malicious web site... The vulnerability was discovered by an individual...who says he contacted Netgear about the flaw four months ago, and went public with information on it after the company failed to address the issue on its own.

"By convincing a user to visit a specially crafted web site, a remote attacker may execute arbitrary commands with root privileges on affected routers," warns a new vulnerability notice from Carnegie Mellon University's CERT. Slashdot reader chicksdaddy quotes Security Ledger's story about certain models of Netgear's routers: Firmware version 1.0.7.2_1.1.93 (and possibly earlier) for the R7000 and version 1.0.1.6_1.0.4 (and possibly earlier) for the R6400 are known to contain the arbitrary command injection vulnerability. CERT cited "community reports" that indicate the R8000, firmware version 1.0.3.4_1.1.2, is also vulnerable... The flaw was found in new firmware that runs the Netgear R7000 and R6400 routers. Other models and firmware versions may also be affected, including the R8000 router, CMU CERT warned.

With no work around to the flaw, CERT recommended that Netgear customers disable their wifi router until a software patch from the company that addressed the hole was available... A search of the public internet using the Shodan search engine finds around 8,000 R6450 and R7000 devices that can be reached directly from the Internet and that would be vulnerable to takeover attacks. The vast majority of those are located in the United States.
Proof-of-concept exploit code was released by a Twitter user who, according to the article, said "he informed Netgear of the flaw more than four months ago, but did not hear back from the company since then."

An anonymous reader writes from a report via Softpedia: "Researcher Jerry Decime revealed details about a security vulnerability that allows an attacker to gain a Man-in-the-Middle position and intercept HTTPS traffic thanks to flaws in the implementation of proxy authentication procedures in various products," reports Softpedia. The flaw can be used to collect user credentials by tricking victims into re-authenticating, sending data to a third-party. Multiple software vendors deploy applications that can handle proxy connections. Until now, Apple, Microsoft, Oracle, and Opera have acknowledged their products are affected. Lenovo said this bug does not impact its software. Other software vendors that are still evaluating the FalseCONNECT bug and may be affected include multiple Linux distros, Cisco, Google, HP, IBM, Juniper, Mozilla, Nokia, OpenBSD, SAP, Sony, and others.

An anonymous reader writes: The US Federal Trade Commission (FTC) has fined a software vendor for lying about its product's encryption capabilities, despite being publicly warned by US Computer Emergency Readiness Team (CERT) not to do so. The software vendor is Henry Schein, who deliberately ignored CERT and FTC warnings and continued to sell its CRM for dentists, even if it knew it did not comply with HIPAA rules. The vendor got "only" a $250,000 fine.

itwbennett writes: Adding fuel to the growing concern over how manufacturers of devices such as routers and smart TVs deal with security vulnerabilities that emerge in their products, Trend Micro found that a 3-year-old vulnerability in a software component used in millions of smart TVs, routers and phones still hasn't been patched by many vendors. Although a patch was issued for the component in December 2012, Trend Micro found 547 apps that use an older unpatched version of it, wrote Veo Zhang, a mobile threats analyst on the Trend Micro blog. 'These are very popular apps that put millions of users in danger; aside from mobile devices, routers, and smart TVs are all at risk as well,' he wrote.

Trailrunner7 writes: The CERT/CC is warning users that some Belkin home routers contain a number of vulnerabilities that could allow an attacker to spoof DNS responses, intercept credentials sent in cleartext, access the web management interface, and take other actions on vulnerable routers. The vulnerabilities affect the Belkin N600 DB Wireless Dual Band N+ router, model F9K1102 v2 with firmware version 2.10.17, and potentially earlier versions of the firmware, as well. The vulnerabilities have not been patched by Belkin, the advisory from the CERT/CC says there aren't any practical workarounds for them. "DNS queries originating from the Belkin N600, such as those to resolve the names of firmware update and NTP servers, use predictable TXIDs that start at 0x0002 and increase incrementally. An attacker with the ability to spoof DNS responses can cause the router to contact incorrect or malicious hosts under the attacker's control," the advisory says.

Trailrunner7 writes: Security issues continue to crop up within the so-called "smart home." A pair of vulnerabilities have been reported for the Tuxedo Touch controller made by Honeywell, a device that's designed to allow users to control home systems such as security, climate control, lighting, and others. The controller, of course, is accessible from the Internet. Researcher Maxim Rupp discovered that the vulnerabilities could allow an attacker to take arbitrary actions, including unlocking doors or modifying the climate controls in the house.

Adesso writes: A serious security problem in the default Samsung keyboard installed on many of the company's cellphones has been lurking since December 2014 (CVE-2015-2865). When the phone tries to update the keyboard, it fails to encrypt the executable file. This means attackers on the same network can replace the update file with a malicious one of their own. Affected devices include the Galaxy S6, S5, S4, and S4 mini — roughly 600 million of which are in use. There's no known fix at the moment, aside from avoiding insecure Wi-Fi networks or switching phones. The researcher who presented these findings at the Blackhat security conference says Samsung has provided a patch to carriers, but he can't find out if any of them have applied the patch. The bug is currently still active on the devices he tested.

PC Magazine reports (as does Ars Technica) that Apple this week has pushed its first automated security update, to address critical flaws relating to Network Time Protocol: The flaws were revealed last week by the Department of Homeland Security and the Carnegie Mellon University Software Engineering Institute—the latter of which identified a number of potentially affected vendors, including FreeBSD Project, NTP Project, OmniTI, and Watchguard Technologies, Inc. A number of versions of the NTP Project "allow attackers to overflow several buffers in a way that may allow malicious code to be executed," the Carnegie Mellon/DHS security bulletin said. ... The company's typical security patches come through Apple's regular software update system, and often require users to move through a series of steps before installing. This week's update, however, marks Cupertino's first implementation of its automated system, despite having introduced the function two years ago, Reuters said.

chicksdaddy writes "The Security Ledger reports that the security firm IOActive has discovered serious security holes in the WeMo home automation technology from Belkin. The vulnerabilities could allow remote attackers to use Belkin's WeMo devices to virtually vandalize connected homes, or as a stepping stone to other computers connected on a home network. IOActive researcher Mike Davis said on Tuesday that his research into Belkin's WeMo technology found the 'devices expose users to several potentially costly threats, from home fires with possible tragic consequences down to the simple waste of electricity.' IOActive provided information on Davis's research to the US Computer Emergency Readiness Team (CERT), which issued an advisory on the WeMo issues on Tuesday. There has been no response yet from Belkin."

msm1267 writes "A serious attack against ciphertext secrets buried inside HTTPS responses has prompted an advisory from Homeland Security. The BREACH attack is an offshoot of CRIME, which was thought dead and buried after it was disclosed in September. Released at last week's Black Hat USA 2013, BREACH enables an attacker to read encrypted messages over the Web by injecting plaintext into an HTTPS request and measuring compression changes. Researchers Angelo Prado, Neal Harris and Yoel Gluck demonstrated the attack against Outlook Web Access (OWA) at Black Hat. Once the Web application was opened and the Breach attack was launched, within 30 seconds the attackers had extracted the secret. 'We are currently unaware of a practical solution to this problem,' said the CERT advisory, released one day after the Black Hat presentation."

hypnosec writes "A new flaw has been discovered in printers manufactured by Samsung whereby a backdoor in the form of an administrator account would enable attackers to not only take control of the flawed device, but will also allow them to attack other systems in the network. According to a warning on US-CERT the administrator account is hard-coded in the device in the form of an SNMP community string with full read-write access. The backdoor is not only present in Samsung printers but also in Dell printers that have been manufactured by Samsung. The administrator account remains active even if SNMP is disabled from the printer's administration interface."

An anonymous reader writes "CERT/CC has called out AMD for having insecure video drivers. AMD/ATI video drivers are incompatible with system-wide ASLR. 'Always On' DEP combined with 'Always On' ASLR are effective exploit mitigations. However, most people don't know about 'Always On' ASLR since Microsoft had to hide it from EMET with an 'EnableUnsafeSettings' registry key — because AMD/ATI video drivers will cause a BSOD on boot if 'Always On' ASLR is enabled."

benrothke writes "While Julius Caesar likely never said 'Et tu, Brute?' the saying associated with his final minutes has come to symbolize the ultimate insider betrayal. In The CERT Guide to Insider Threats: How to Prevent, Detect, and Respond to Information Technology Crimes, authors Dawn Cappelli, Andrew Moore and Randall Trzeciak of the CERT Insider Threat Center provide incontrovertible data and an abundance of empirical evidence, which creates an important resource on the topic of insider threats. There are thousands of companies that have uttered modern day versions of Et tu, Brute due to insidious insider attacks and the book documents many of them." Read on for the rest of Ben's review. The CERT Guide to Insider Threats: How to Prevent, Detect, and Respond to Information Technology Crimes author Dawn Cappelli, Andrew Moore, Randall Trzeciak pages 432 publisher Addison-Wesley Professional rating 10/10 reviewer Ben Rothke ISBN 978-0321812575 summary Definitive resource on insider threats The book is based on work done at the CERT Insider Threat Center, which has been researching this topic for the last decade. The data the threat center has access to is unparalleled, which in turn makes this the definitive book on the topic. The threat center has investigated nearly 1,000 incidents and their data sets on the topic are unrivaled. With that, the book truly needs to be on the desktop of everyone tasked with data security and intellectual property protection.

The book provides a unique perspective on insider threats as the CERT Insider Threat Center pioneered the study of the topic, and has exceptional and empirical data to back up their findings. While there are many books on important security topics such as firewalls, encryption, identity management and more; The CERT Guide to Insider Threats is the one of the first to formally and effectively tackle the extraordinary devastating problem of trusted insiders who misappropriate data.

In the introduction, the authors write that a common misconception is that insider threat risk management is the responsibility of IT and information security staff members exclusively. The reality is that it is the responsibility of senior management to ensure that there is an overarching program to deal with insider threats at the enterprise level. Surpassingly and shockingly, far too few organizations have insider threat programs in place, and the book has scores of stories and case studies on those organizations that have become victims. While senior management created information security solutions to secure the perimeter; they were oblivious to the data leakage emanating from the interior network.

The authors reiterate that it is critical that all levels of management recognize and acknowledge the threat posed by insiders and take appropriate steps to mitigate malicious insiders. While it is impossible to stop every attack, what management can certainly do is build resiliency into their organizations infrastructure and business processes. This enables the organization to detect the attacks earlier and minimize the financial and operational impact. The book provides the specific details on how an organization can precisely do that.

In 9 detailed chapters and 6 appendices, the book provides a comprehensive and exhaustive analysis of the problem and menace of insider threats. After completing the book, one is well-prepared to initiate an insider threat program. The book provides examples of insider crimes from nearly every industry segment and ample data to share with management to convince them that the threats, both to their intellectual property and corporate profits, are very real.

After a high-level overview of the topic in chapter 1, the next chapter gets into the details of insider IT sabotage. While some think that stopping IT sabotage is next to impossible, the authors detail and have identified distinct patterns in nearly every IT sabotage case. The book details those patterns and also presents mitigation strategies, both technical and non-technical, to deal with those threats.

The chapter provides fascinating insights into how these crimes are carried out. The authors note that by their very nature, these attacks require technical sophistication and privileged access and are usually carried out by sysadmins, DBA's and programmers. A surprising CERT finding is that the majority of the attacks occur after the insider has been terminated or quit the organization. Part of the problem is that many organizations don't have a process in place to immediately terminate access when a worker resigns or is fired. In addition, 25% of the cases were carried out by full-time contractors.

Chapter 3 provides an intriguing look at the issue of insider theft of intellectual property (IP). Any firm that has a sizable amount invested in their IP (i.e., anything you can put on a USB stick) needs to take this chapter to heart. One of the many misconceptions CERT research has uncovered on this topic is that sysadmins are indeed not the biggest threat to IP, even though they have complete access to networks, systems and data.

According to the CERT data, they have not found a single case in which a sysadmin stole IP. Rather the biggest threat to IP is insider theft by scientists, engineers, programmers or salespeople. Also, CERT found that about a third of the IP cases were carried out for the benefit of a foreign government of organization, with China having more cases of IP theft than the other 9 countries combined.

Given the nature of China and its appetite for data theft, the book is surprisingly silent on specific suggestions in which to deal with threats from China. I would have liked to have seen at least a chapter dedicated to this topic.

The chapter continues and provides detailed lists of issues leading to job dissatisfaction that can lead a trusted employee or contractor to commit IP theft, and provides detailed steps on what companies can do to stop it.

Chapter 4 details everything you need to know about insider fraud. A fascinating statistic detailed is that the average insider fraud crime spans about 15 months, with half of the crimes lasting 5 months or more. The authors write that insider fraud is typically a long and ingoing crime. All of this is happening, over the course of months and years, and the organizations being pilfered are oblivious to it.

The book is worth reading for chapter 6 alone, which details best practices for the prevention and detection of insider threats. The best practices in chapter 6 give the reader a framework for establishing an insider threat program. Many of the best practices detailed are elements of a good security program, so they should not be news to anyone. Some of the best practices include: security awareness training, physical security controls, separation of duties, and perhaps the most blatantly obvious suggestion of them all: deactivate access following termination.

Another fascinating fact detailed in the book is that almost all insiders involved in acts of IT sabotage displayed behavioral indicators prior to committing their crimes. Some of those indicators include: conflicts with coworkers or supervisors, improper use of data assets, sanctions and rule violations. Organizations that act on these precursors can prevent the insider crimes from taking place.

Aside from its lack of coverage on how to specifically deal with the China threat, the only other lacking in the book is that in all of the examples and case studies, even those whose breaches are publicly known, organizations are not mentioned by name.

According to author Dawn Cappelli, Technical Manager at the CERT Insider Threat Center, they took that approach based on interviews for approximately 230 of their cases, with prosecutors, investigators, victim organization, or convicted insiders. In those interviews they guaranteed confidentiality of the information they obtained. Therefore, CERT considers the success of their research directly related to their reputation in the community for being trustworthy for maintaining confidentiality. While there reasoning makes sense, anonymous case studies are often unsatisfying

Insider threats are pervasive and indisputable. Organizations such as the CERT Insider Threat Center and individuals like Antonio Rucci provide vital services evangelizing about this critical topic. This entertaining video of Rucci from DEFCON 17 is a great primer on the topic.

Most of the firms who fall victim to insider threats are oblivious to them as they occur. The book details effective and operational security practices which can help every organization create an insider threat program to counterattack the majority of insider attacks.

When it comes to insider threats, the only way to avert them is to have a prevention program in place. In The CERT Guide to Insider Threats: How to Prevent, Detect, and Respond to Information Technology Crimes, the authors have created an invaluable guidebook, with myriad details in which to enable the reader do that. The facts around insider threats speak for themselves. Anyone charged with protection of corporate data should ensure this book is on their required reading list. If not, and they fall victim to an insider attack, they have no one to blame but themselves.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase The CERT Guide to Insider Threats: How to Prevent, Detect, and Respond to Information Technology Crimes from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Trailrunner7 writes "There is a newly discovered vulnerability in the WiFi Protected Setup standard that reduces the number of attempts it would take an attacker to brute-force the PIN for a wireless router's setup process. The flaw results in too much information about the PIN being returned to an attacker and makes the PIN quite weak, affecting the security of millions of WiFi routers and access points. Security researcher Stefan Viehbock discovered the vulnerability (PDF) and reported it to US-CERT. The problem affects a number of vendors' products, including D-Link, Netgear, Linksys and Buffalo. 'I noticed a few really bad design decisions which enable an efficient brute force attack, thus effectively breaking the security of pretty much all WPS-enabled Wi-Fi routers. As all of the of the more recent router models come with WPS enabled by default, this affects millions of devices worldwide,' Viehbock said."

brothke writes "If Gartner were to have created the CERT-RMM framework like what is detailed in the book CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience; it likely would be offered to their clients for at least $15,000. With a list price of $79.99, the book is clearly a bargain. Besides being inexpensive, it details an invaluable model that should be seriously considered by nearly every organization." Keep reading for the rest of Ben's review. CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience author Richard Caralli, Julia Allen, David White pages 1056 publisher Addison-Wesley Professional rating 10/10 reviewer Ben Rothke ISBN 0321712439 summary Book details a superb method to tame the out of control world of IT operations The CERT-RMM is a capability model for operational resilience management. Put more simply; it is a method to tame the out of control world of IT operations.

CERT notes that the model has two primary objectives: to establish the convergence of operational risk and resilience management activities such as security, business continuity, and aspects of IT operations management into a single model. And to apply a process improvement approach to operational resilience management through the definition and application of a capability level scale that expresses increasing levels of process improvement.

In plain English, the model creates a formal method in which to execute IT tasks. Given the reality that most IT tasks are executed in an ad-hoc manner, the CERT-RMM should be a welcome relief to most organizations.

The CERT-RMM is a relatively new framework, with version 1.0 being issued in May 2010. Version 1.1 was made available via this book in December 2010. CERT also has a really good CERT-RMM Overview presentation available.

CERT-RMM v1.1 comprises 26 process areas that cover four areas of operations resilience management: enterprise management, engineering, operations and process management.

In chapter 1, the authors astutely note that technology can be very effective in managing risk, but technology cannot always substitute for skilled peoples and resources, procedures and methods that define and connect tasks and activities, and processes to provide structure and stability towards the achievement of common objectives and goals.

The problem is that most companies will spend huge amounts of money on these myriad technologies and seemingly expect the install routine to magically integrate the numerous processes. CERT-RMM is a comprehensive solution to a broad set of problems.

But for those that are looking to CERT-RMM for a quick fix to a decades old problem, the authors also note in chapter 1 that CERT-RMM must be embedded within the culture and practices of an organization. The CERT-RMM practices will only make an organization more resilient to the degree to which they have been institutionalized via its processes.

At just over 1,000 pages, the book is a treasure-trove of invaluable information. While the amount of information may be overwhelming, it is manageable if used in a serious fashion. But just to reiterate, CERT-RMM should not be seen as a quick-fix solution.

The main textual part of the book covers 2 parts and 7 chapters which make up the first 120 pages. These 2 parts provide a comprehensive overview of the CERT-RMM and provides an overview of the various concepts used within the model. The authors do a superb job of showing how structure and processes need to be an integral part of enterprise operations, and note the challenges of not having such an approach.

Focusing on information security, the authors intelligently observe in chapter 2 that historically information was viewed as a technology problem and relegated to the IT department. The problem though with such an approach is that when an incident or disruption occurs, the response is generally localized and discrete; not orchestrated across all affected lines of business and organizational units. That problem is precisely what CERT-RMM comes to fix. If implemented effectively, the processes enable organizations to respond in a more formal manner, with integrated processes; resulting in operations that are quicker, cheaper, and ultimately, more resilient.

In chapter 4, the authors tell you what seems to be obvious: that the CERT-RMM in its entirety looks ominous. They note the reason is that operational resilience management encompasses many disciplines and practices. The challenge though is for the organization to be able to understand the relationships in the CERT-RMM model and connect them to their own organization. CERT-RMM is certainly not for the fainthearted. But for those that are serious about operational efficiency and resilience, CERT-RMM is certainly a godsend.

The reality is that not only does the CERT-RMM look ominous, it is. The reason is that CERT-RMM will most likely be used to retrofit an organization that has used decades of ad-hoc approaches to its IT processes. Trying to fix so much is indeed ominous. But even with that ominous cloud, it is something that must be done.

In chapter 5, the authors make an important point in that CERT-RMM is not a prescriptive model. This means that there is no guidance provided to adopt the model in any specific sequence or prescriptive path. Rather, process improvements are unique to each organization, to which the CERT-RMM provides the basic structure to enable enterprises to chart their own specific improvements paths uses the model as a guide.

Chapter 6 on Using CERT-RMM notes that the model has a strong enterprise undercurrent, due to the fact that effective operational resilience management requires capabilities that often have enterprise-wide significant. But the enterprise–wide nature of the model does not mean that it can't be adopted at more discrete levels.

Part 3 of the book is a complete listing of the 26 CERT-RMM process areas. Part 3 is where the heart of the CERT-RMM is. Each of the 26 sections has a complete set of descriptions of goals and practices and real-world examples.

Think of part 3 as The Checklist Manifesto: How to Get Things Right, but on steroids. In that book, author Atul Gawande uses the notion of a checklist as a quality-control device. He noticed that the high-pressure complexities in place today can overwhelm even the best-trained professional and that only a disciplined adherence to essential procedures can fix things. Gawande would likely be enamored by the CERT-RMM.

When the reader goes through the over 800 pages of part 3, they will see them as a set of standard operating procedures (SOP). Industries such as aviation, manufacturing and pharmaceuticals have SOP deeply embedded in their processes. The SOP in part 3 are far from rocket science. They are simply a comprehensive approach and attention to detail. Given that resilience is all about the details, part 3 can be used to take an organization to a mature state of resilience.

If nothing else, part 3 should give the reader an appreciation for the need for effective process around IT initiatives. The exacting level of detail described in part 3 displays a rigorous set of processes that if deployed, can ensure an all-embracing approach to systems management and control.

Often books with numerous authors lack a sense of style and symmetry. With 3 authors, the book suffers none of that and is completely integrated into a single unit with no disconnects. Each of the authors are CERT veterans that bring considerable experience which is pervasive throughout the book.

But as good as the CERT-RMM, we all know that it is likely to have minimal adoption. Most organizations are far too short-sighted to use a model that requires such discipline and long-term approach asCERT-RMM.

But for those organizations that are truly serious about resiliency, serious about security, serious about saving money and being more efficient, this book and the CERT-RMM is a model they will embrace warmly. This book is an important first step that can be the gateway to resiliency.

For all the others, they should at least use the CERT-RMM incident management and controlprocess area to deal with the many security incidents and breaches they will inevitably have to contend with.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brothke writes "If Gartner were to have created the CERT-RMM framework like what is detailed in the book CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience; it likely would be offered to their clients for at least $15,000. With a list price of $79.99, the book is clearly a bargain. Besides being inexpensive, it details an invaluable model that should be seriously considered by nearly every organization." Keep reading for the rest of Ben's review. CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience author Richard Caralli, Julia Allen, David White pages 1056 publisher Addison-Wesley Professional rating 10/10 reviewer Ben Rothke ISBN 0321712439 summary Book details a superb method to tame the out of control world of IT operations The CERT-RMM is a capability model for operational resilience management. Put more simply; it is a method to tame the out of control world of IT operations.

CERT notes that the model has two primary objectives: to establish the convergence of operational risk and resilience management activities such as security, business continuity, and aspects of IT operations management into a single model. And to apply a process improvement approach to operational resilience management through the definition and application of a capability level scale that expresses increasing levels of process improvement.

In plain English, the model creates a formal method in which to execute IT tasks. Given the reality that most IT tasks are executed in an ad-hoc manner, the CERT-RMM should be a welcome relief to most organizations.

The CERT-RMM is a relatively new framework, with version 1.0 being issued in May 2010. Version 1.1 was made available via this book in December 2010. CERT also has a really good CERT-RMM Overview presentation available.

CERT-RMM v1.1 comprises 26 process areas that cover four areas of operations resilience management: enterprise management, engineering, operations and process management.

In chapter 1, the authors astutely note that technology can be very effective in managing risk, but technology cannot always substitute for skilled peoples and resources, procedures and methods that define and connect tasks and activities, and processes to provide structure and stability towards the achievement of common objectives and goals.

The problem is that most companies will spend huge amounts of money on these myriad technologies and seemingly expect the install routine to magically integrate the numerous processes. CERT-RMM is a comprehensive solution to a broad set of problems.

But for those that are looking to CERT-RMM for a quick fix to a decades old problem, the authors also note in chapter 1 that CERT-RMM must be embedded within the culture and practices of an organization. The CERT-RMM practices will only make an organization more resilient to the degree to which they have been institutionalized via its processes.

At just over 1,000 pages, the book is a treasure-trove of invaluable information. While the amount of information may be overwhelming, it is manageable if used in a serious fashion. But just to reiterate, CERT-RMM should not be seen as a quick-fix solution.

The main textual part of the book covers 2 parts and 7 chapters which make up the first 120 pages. These 2 parts provide a comprehensive overview of the CERT-RMM and provides an overview of the various concepts used within the model. The authors do a superb job of showing how structure and processes need to be an integral part of enterprise operations, and note the challenges of not having such an approach.

Focusing on information security, the authors intelligently observe in chapter 2 that historically information was viewed as a technology problem and relegated to the IT department. The problem though with such an approach is that when an incident or disruption occurs, the response is generally localized and discrete; not orchestrated across all affected lines of business and organizational units. That problem is precisely what CERT-RMM comes to fix. If implemented effectively, the processes enable organizations to respond in a more formal manner, with integrated processes; resulting in operations that are quicker, cheaper, and ultimately, more resilient.

In chapter 4, the authors tell you what seems to be obvious: that the CERT-RMM in its entirety looks ominous. They note the reason is that operational resilience management encompasses many disciplines and practices. The challenge though is for the organization to be able to understand the relationships in the CERT-RMM model and connect them to their own organization. CERT-RMM is certainly not for the fainthearted. But for those that are serious about operational efficiency and resilience, CERT-RMM is certainly a godsend.

The reality is that not only does the CERT-RMM look ominous, it is. The reason is that CERT-RMM will most likely be used to retrofit an organization that has used decades of ad-hoc approaches to its IT processes. Trying to fix so much is indeed ominous. But even with that ominous cloud, it is something that must be done.

In chapter 5, the authors make an important point in that CERT-RMM is not a prescriptive model. This means that there is no guidance provided to adopt the model in any specific sequence or prescriptive path. Rather, process improvements are unique to each organization, to which the CERT-RMM provides the basic structure to enable enterprises to chart their own specific improvements paths uses the model as a guide.

Chapter 6 on Using CERT-RMM notes that the model has a strong enterprise undercurrent, due to the fact that effective operational resilience management requires capabilities that often have enterprise-wide significant. But the enterprise–wide nature of the model does not mean that it can't be adopted at more discrete levels.

Part 3 of the book is a complete listing of the 26 CERT-RMM process areas. Part 3 is where the heart of the CERT-RMM is. Each of the 26 sections has a complete set of descriptions of goals and practices and real-world examples.

Think of part 3 as The Checklist Manifesto: How to Get Things Right, but on steroids. In that book, author Atul Gawande uses the notion of a checklist as a quality-control device. He noticed that the high-pressure complexities in place today can overwhelm even the best-trained professional and that only a disciplined adherence to essential procedures can fix things. Gawande would likely be enamored by the CERT-RMM.

When the reader goes through the over 800 pages of part 3, they will see them as a set of standard operating procedures (SOP). Industries such as aviation, manufacturing and pharmaceuticals have SOP deeply embedded in their processes. The SOP in part 3 are far from rocket science. They are simply a comprehensive approach and attention to detail. Given that resilience is all about the details, part 3 can be used to take an organization to a mature state of resilience.

If nothing else, part 3 should give the reader an appreciation for the need for effective process around IT initiatives. The exacting level of detail described in part 3 displays a rigorous set of processes that if deployed, can ensure an all-embracing approach to systems management and control.

Often books with numerous authors lack a sense of style and symmetry. With 3 authors, the book suffers none of that and is completely integrated into a single unit with no disconnects. Each of the authors are CERT veterans that bring considerable experience which is pervasive throughout the book.

But as good as the CERT-RMM, we all know that it is likely to have minimal adoption. Most organizations are far too short-sighted to use a model that requires such discipline and long-term approach asCERT-RMM.

But for those organizations that are truly serious about resiliency, serious about security, serious about saving money and being more efficient, this book and the CERT-RMM is a model they will embrace warmly. This book is an important first step that can be the gateway to resiliency.

For all the others, they should at least use the CERT-RMM incident management and controlprocess area to deal with the many security incidents and breaches they will inevitably have to contend with.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brothke writes "If Gartner were to have created the CERT-RMM framework like what is detailed in the book CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience; it likely would be offered to their clients for at least $15,000. With a list price of $79.99, the book is clearly a bargain. Besides being inexpensive, it details an invaluable model that should be seriously considered by nearly every organization." Keep reading for the rest of Ben's review. CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience author Richard Caralli, Julia Allen, David White pages 1056 publisher Addison-Wesley Professional rating 10/10 reviewer Ben Rothke ISBN 0321712439 summary Book details a superb method to tame the out of control world of IT operations The CERT-RMM is a capability model for operational resilience management. Put more simply; it is a method to tame the out of control world of IT operations.

CERT notes that the model has two primary objectives: to establish the convergence of operational risk and resilience management activities such as security, business continuity, and aspects of IT operations management into a single model. And to apply a process improvement approach to operational resilience management through the definition and application of a capability level scale that expresses increasing levels of process improvement.

In plain English, the model creates a formal method in which to execute IT tasks. Given the reality that most IT tasks are executed in an ad-hoc manner, the CERT-RMM should be a welcome relief to most organizations.

The CERT-RMM is a relatively new framework, with version 1.0 being issued in May 2010. Version 1.1 was made available via this book in December 2010. CERT also has a really good CERT-RMM Overview presentation available.

CERT-RMM v1.1 comprises 26 process areas that cover four areas of operations resilience management: enterprise management, engineering, operations and process management.

In chapter 1, the authors astutely note that technology can be very effective in managing risk, but technology cannot always substitute for skilled peoples and resources, procedures and methods that define and connect tasks and activities, and processes to provide structure and stability towards the achievement of common objectives and goals.

The problem is that most companies will spend huge amounts of money on these myriad technologies and seemingly expect the install routine to magically integrate the numerous processes. CERT-RMM is a comprehensive solution to a broad set of problems.

But for those that are looking to CERT-RMM for a quick fix to a decades old problem, the authors also note in chapter 1 that CERT-RMM must be embedded within the culture and practices of an organization. The CERT-RMM practices will only make an organization more resilient to the degree to which they have been institutionalized via its processes.

At just over 1,000 pages, the book is a treasure-trove of invaluable information. While the amount of information may be overwhelming, it is manageable if used in a serious fashion. But just to reiterate, CERT-RMM should not be seen as a quick-fix solution.

The main textual part of the book covers 2 parts and 7 chapters which make up the first 120 pages. These 2 parts provide a comprehensive overview of the CERT-RMM and provides an overview of the various concepts used within the model. The authors do a superb job of showing how structure and processes need to be an integral part of enterprise operations, and note the challenges of not having such an approach.

Focusing on information security, the authors intelligently observe in chapter 2 that historically information was viewed as a technology problem and relegated to the IT department. The problem though with such an approach is that when an incident or disruption occurs, the response is generally localized and discrete; not orchestrated across all affected lines of business and organizational units. That problem is precisely what CERT-RMM comes to fix. If implemented effectively, the processes enable organizations to respond in a more formal manner, with integrated processes; resulting in operations that are quicker, cheaper, and ultimately, more resilient.

In chapter 4, the authors tell you what seems to be obvious: that the CERT-RMM in its entirety looks ominous. They note the reason is that operational resilience management encompasses many disciplines and practices. The challenge though is for the organization to be able to understand the relationships in the CERT-RMM model and connect them to their own organization. CERT-RMM is certainly not for the fainthearted. But for those that are serious about operational efficiency and resilience, CERT-RMM is certainly a godsend.

The reality is that not only does the CERT-RMM look ominous, it is. The reason is that CERT-RMM will most likely be used to retrofit an organization that has used decades of ad-hoc approaches to its IT processes. Trying to fix so much is indeed ominous. But even with that ominous cloud, it is something that must be done.

In chapter 5, the authors make an important point in that CERT-RMM is not a prescriptive model. This means that there is no guidance provided to adopt the model in any specific sequence or prescriptive path. Rather, process improvements are unique to each organization, to which the CERT-RMM provides the basic structure to enable enterprises to chart their own specific improvements paths uses the model as a guide.

Chapter 6 on Using CERT-RMM notes that the model has a strong enterprise undercurrent, due to the fact that effective operational resilience management requires capabilities that often have enterprise-wide significant. But the enterprise–wide nature of the model does not mean that it can't be adopted at more discrete levels.

Part 3 of the book is a complete listing of the 26 CERT-RMM process areas. Part 3 is where the heart of the CERT-RMM is. Each of the 26 sections has a complete set of descriptions of goals and practices and real-world examples.

Think of part 3 as The Checklist Manifesto: How to Get Things Right, but on steroids. In that book, author Atul Gawande uses the notion of a checklist as a quality-control device. He noticed that the high-pressure complexities in place today can overwhelm even the best-trained professional and that only a disciplined adherence to essential procedures can fix things. Gawande would likely be enamored by the CERT-RMM.

When the reader goes through the over 800 pages of part 3, they will see them as a set of standard operating procedures (SOP). Industries such as aviation, manufacturing and pharmaceuticals have SOP deeply embedded in their processes. The SOP in part 3 are far from rocket science. They are simply a comprehensive approach and attention to detail. Given that resilience is all about the details, part 3 can be used to take an organization to a mature state of resilience.

If nothing else, part 3 should give the reader an appreciation for the need for effective process around IT initiatives. The exacting level of detail described in part 3 displays a rigorous set of processes that if deployed, can ensure an all-embracing approach to systems management and control.

Often books with numerous authors lack a sense of style and symmetry. With 3 authors, the book suffers none of that and is completely integrated into a single unit with no disconnects. Each of the authors are CERT veterans that bring considerable experience which is pervasive throughout the book.

But as good as the CERT-RMM, we all know that it is likely to have minimal adoption. Most organizations are far too short-sighted to use a model that requires such discipline and long-term approach asCERT-RMM.

But for those organizations that are truly serious about resiliency, serious about security, serious about saving money and being more efficient, this book and the CERT-RMM is a model they will embrace warmly. This book is an important first step that can be the gateway to resiliency.

For all the others, they should at least use the CERT-RMM incident management and controlprocess area to deal with the many security incidents and breaches they will inevitably have to contend with.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brothke writes "If Gartner were to have created the CERT-RMM framework like what is detailed in the book CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience; it likely would be offered to their clients for at least $15,000. With a list price of $79.99, the book is clearly a bargain. Besides being inexpensive, it details an invaluable model that should be seriously considered by nearly every organization." Keep reading for the rest of Ben's review. CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience author Richard Caralli, Julia Allen, David White pages 1056 publisher Addison-Wesley Professional rating 10/10 reviewer Ben Rothke ISBN 0321712439 summary Book details a superb method to tame the out of control world of IT operations The CERT-RMM is a capability model for operational resilience management. Put more simply; it is a method to tame the out of control world of IT operations.

CERT notes that the model has two primary objectives: to establish the convergence of operational risk and resilience management activities such as security, business continuity, and aspects of IT operations management into a single model. And to apply a process improvement approach to operational resilience management through the definition and application of a capability level scale that expresses increasing levels of process improvement.

In plain English, the model creates a formal method in which to execute IT tasks. Given the reality that most IT tasks are executed in an ad-hoc manner, the CERT-RMM should be a welcome relief to most organizations.

The CERT-RMM is a relatively new framework, with version 1.0 being issued in May 2010. Version 1.1 was made available via this book in December 2010. CERT also has a really good CERT-RMM Overview presentation available.

CERT-RMM v1.1 comprises 26 process areas that cover four areas of operations resilience management: enterprise management, engineering, operations and process management.

In chapter 1, the authors astutely note that technology can be very effective in managing risk, but technology cannot always substitute for skilled peoples and resources, procedures and methods that define and connect tasks and activities, and processes to provide structure and stability towards the achievement of common objectives and goals.

The problem is that most companies will spend huge amounts of money on these myriad technologies and seemingly expect the install routine to magically integrate the numerous processes. CERT-RMM is a comprehensive solution to a broad set of problems.

But for those that are looking to CERT-RMM for a quick fix to a decades old problem, the authors also note in chapter 1 that CERT-RMM must be embedded within the culture and practices of an organization. The CERT-RMM practices will only make an organization more resilient to the degree to which they have been institutionalized via its processes.

At just over 1,000 pages, the book is a treasure-trove of invaluable information. While the amount of information may be overwhelming, it is manageable if used in a serious fashion. But just to reiterate, CERT-RMM should not be seen as a quick-fix solution.

The main textual part of the book covers 2 parts and 7 chapters which make up the first 120 pages. These 2 parts provide a comprehensive overview of the CERT-RMM and provides an overview of the various concepts used within the model. The authors do a superb job of showing how structure and processes need to be an integral part of enterprise operations, and note the challenges of not having such an approach.

Focusing on information security, the authors intelligently observe in chapter 2 that historically information was viewed as a technology problem and relegated to the IT department. The problem though with such an approach is that when an incident or disruption occurs, the response is generally localized and discrete; not orchestrated across all affected lines of business and organizational units. That problem is precisely what CERT-RMM comes to fix. If implemented effectively, the processes enable organizations to respond in a more formal manner, with integrated processes; resulting in operations that are quicker, cheaper, and ultimately, more resilient.

In chapter 4, the authors tell you what seems to be obvious: that the CERT-RMM in its entirety looks ominous. They note the reason is that operational resilience management encompasses many disciplines and practices. The challenge though is for the organization to be able to understand the relationships in the CERT-RMM model and connect them to their own organization. CERT-RMM is certainly not for the fainthearted. But for those that are serious about operational efficiency and resilience, CERT-RMM is certainly a godsend.

The reality is that not only does the CERT-RMM look ominous, it is. The reason is that CERT-RMM will most likely be used to retrofit an organization that has used decades of ad-hoc approaches to its IT processes. Trying to fix so much is indeed ominous. But even with that ominous cloud, it is something that must be done.

In chapter 5, the authors make an important point in that CERT-RMM is not a prescriptive model. This means that there is no guidance provided to adopt the model in any specific sequence or prescriptive path. Rather, process improvements are unique to each organization, to which the CERT-RMM provides the basic structure to enable enterprises to chart their own specific improvements paths uses the model as a guide.

Chapter 6 on Using CERT-RMM notes that the model has a strong enterprise undercurrent, due to the fact that effective operational resilience management requires capabilities that often have enterprise-wide significant. But the enterprise–wide nature of the model does not mean that it can't be adopted at more discrete levels.

Part 3 of the book is a complete listing of the 26 CERT-RMM process areas. Part 3 is where the heart of the CERT-RMM is. Each of the 26 sections has a complete set of descriptions of goals and practices and real-world examples.

Think of part 3 as The Checklist Manifesto: How to Get Things Right, but on steroids. In that book, author Atul Gawande uses the notion of a checklist as a quality-control device. He noticed that the high-pressure complexities in place today can overwhelm even the best-trained professional and that only a disciplined adherence to essential procedures can fix things. Gawande would likely be enamored by the CERT-RMM.

When the reader goes through the over 800 pages of part 3, they will see them as a set of standard operating procedures (SOP). Industries such as aviation, manufacturing and pharmaceuticals have SOP deeply embedded in their processes. The SOP in part 3 are far from rocket science. They are simply a comprehensive approach and attention to detail. Given that resilience is all about the details, part 3 can be used to take an organization to a mature state of resilience.

If nothing else, part 3 should give the reader an appreciation for the need for effective process around IT initiatives. The exacting level of detail described in part 3 displays a rigorous set of processes that if deployed, can ensure an all-embracing approach to systems management and control.

Often books with numerous authors lack a sense of style and symmetry. With 3 authors, the book suffers none of that and is completely integrated into a single unit with no disconnects. Each of the authors are CERT veterans that bring considerable experience which is pervasive throughout the book.

But as good as the CERT-RMM, we all know that it is likely to have minimal adoption. Most organizations are far too short-sighted to use a model that requires such discipline and long-term approach asCERT-RMM.

But for those organizations that are truly serious about resiliency, serious about security, serious about saving money and being more efficient, this book and the CERT-RMM is a model they will embrace warmly. This book is an important first step that can be the gateway to resiliency.

For all the others, they should at least use the CERT-RMM incident management and controlprocess area to deal with the many security incidents and breaches they will inevitably have to contend with.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase CERT Resilience Management Model (RMM): A Maturity Model for Managing Operational Resilience from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

infoLaw passes along this excerpt from Threatpost: "Carnegie Mellon University's Computer Emergency Response Team has released a new fuzzing framework to help identify and eliminate security vulnerabilities from software products. The Basic Fuzzing Framework (BFF) is described as a simplified version of automated dumb fuzzing. It includes a Linux virtual machine that has been optimized for fuzz testing and a set of scripts to implement a software test."

swandives writes "Researchers at US-CERT have warned that software accompanying the Energizer DUO USB battery charger contains a Trojan that gives hackers total access to a Windows PC. The product was sold in the US, Latin America, Europe and Asia starting in 2007. Upon installation, the software creates the file 'Arucer.dll,' a Trojan that listens for commands on TCP port 7777. Upon receiving instructions, the Trojan can download and execute files, transmit files stolen from the PC, or tweak the Windows registry. Uninstalling the software disables the automatic execution of the Trojan. Users can also remove Arucer.dll from Windows' system32 directory and reboot the machine to disable the backdoor component."

An anonymous reader writes "Researchers from the University of Arizona have released a study that takes a look at the security of ten popular package managers. They were able to show all ten were vulnerable to attacks from a mirror or man-in-the-middle that allow an attacker to (along with other things) crash the system or obtain root access. Furthermore, the researchers created a fictitious administrator and company name and were able to lease a server and get it listed as an official mirror for all the distributions they tried (Ubuntu, Debian, Fedora, CentOS, and OpenSUSE). This raised the question: What keeps you up at night, the thought of attacks on your package manager or previously discussed and patched vulnerability in DNS?" justin samuel (one of the Arizona researchers) also points out a synopsis on CERT's blog.

Ben Rothke writes "It is 2008 and never has so much been spent in information security. Year after year, more and more security hardware and software is purchased, more and more security professionals are hired, and more security is done; yet things are not getting better. Every indicator, every pundit, everything points to more security breaches, vulnerabilities and incidents. Large amounts of proprietary data are compromised on a daily basis. Obviously something is wrong, yet the entire industry goes along thinking things are getting better and more secure. Obviously something needs to change. And that new change is what The New School of Information Security attempts to conceive." The New School of Information Security author Adam Shostack and Andrew Stewart pages 288 publisher Addison-Wesley rating 9 reviewer Ben Rothke ISBN 978-0321502780 summary Information security is highly broken; this book suggests a realistic fix. Far too much of the security industry has its roots in FUD. Billions of dollars of information security products have been sold, and for what? The book asks why is information security so dysfunctional and why companies are often wasting so much money on security. So what is this thing called the new school? The authors define it as neither a service nor a product; rather it is a new approach that uses the scientific method and objective data. This in turn gives an entirely new perspective from diverse fields to make effective security decisions. The authors rightly believe that when objective data is used, it enables better decision-making.

The New School of Information Security is a ground-breaking text in that it attempts to remove the reader from the hype of information security, and enables the reader to focus on the realities of security. The fact that such a book needs to be written in 2008 shows the sorry state of information security.

The book starts out with observations of why there are so many failures within information security. Anyone with experience in security can easily relate to these issues. One recurring theme throughout the book is that poor data, be it research or advertising negatively effects the state of security. The authors astutely note that security advertising often does a disservice to the security field because it glosses over complex problems and presents the illusions of a reality in which a security panacea exists. It makes the buyer believe they can reach that panacea by using their service or purchasing their product.

In creating their new school, the authors have no qualms in attacking the dogma of the current state of information security. From Gartner to the Executive Alliance and more, the authors show that these groups and more often suffer from issues such as bias, lack of a scientific method and more. The book notes that the search for objective data on information security is at the heart of the philosophy of the new school. Since there is a drought of objective data today, the book asks how can we know that the conventional wisdom is the right thing to do? The observation is that the current state of affairs is unsustainable for the commercial security industry and for security practitioners.

The title of chapter 5 gives away the theme of the book — Amateurs Study Cryptography — Professionals Study Economics. The idea is that information security must do a better job of embracing such diverse fields as economics, psychology, sociology and more, to make effective decisions.

In some ways, the authors are perhaps too aggressive in their desire for security statistics. One of the most scientific approaches to information security is from CERT (www.cert.org). Yet the authors are not satisfied with CERT's findings that the majority of incidents appear to be insider based. Given what data and statistics we have in 2008, the figures from CERT are certainly good enough. Yes, they could be better, and yes, breach data is not actuarial data, but given the data from CERT, combined with recent news and court cases (UBS, Société Générale,etc.) clearly show that insiders are the most insidious threat.

Also, while the current state of information security is indeed less than perfect, the authors are a bit too condescending of areas where security is formalized (ISO 27001, etc.), yet not perfect.

After years of countless 1,000+ page massive security books, The New School of Information Security succinctly spreads its message in a brief 160 pages. In those 160 pages, the author's detail at a high-level what needs to be done to create this new school. Therein lays the books only flaw, its brevity. The authors want to get the concept of the new school out there, but they do not detail enough of the necessary requirement to make it work. They show with clarity how things are broken, but don't do enough to show how to fix it. Let's hope the authors are at work on a follow-up writing those necessary additions.

Some Slashdot readers are likely to question how an author (Shostack) can write a book on security while being employed by Microsoft. Even with all its security issues, what many do not realize is that no software company has spent more on security in the past decade than Microsoft. Indeed they have a lot of catching up to do, but it is being done. Put another way, Microsoft has likely spent more on security than China has spent on democracy.

Too much of information security is clearly broke and The New School of Information Security is about fixing it. The author's pragmatic approach is a refreshing respite from years of security product based FUD and silver-bullet solutions. The approach of the new school is one that screams out to be put into place. It is the job of today's CISO's and CIO's to heed that call, take the initiative, and lead their organizations there. Either they graduate their staff from the new school, or we are faced with more decades of information security failures.

Let's hope The New School of Information Security is indeed a new start for information security. The book is practical and pragmatic, and one of the most important security books of the last few years. Those serious about information security should definitely read it, and encourage others to do the same.

Ben Rothke is a security consultant with BT and the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase The New School of Information Security from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Enon writes "eEye Digital Security has discovered 14 vulnerabilities in the FLAC file format that affect a huge range of media players on every supported operating system (Windows, Mac OS, Linux, Unix, BSD, Solaris, and even some hardware players are vulnerable). Heise points out a number of vulnerable apps that use the open source libavcodec audio codec library, which in turn relies on the flawed libFLAC library. These vulnerabilities could allow a person of ill will to trojanize FLAC files that could compromise your computer if they are played on a vulnerable media player. eEye worked with US-CERT to notify vulnerable vendors."

LordNikon writes "According to this CERT advisory: 'Full-width and half-width encoding is a technique for encoding Unicode characters. Various HTTP content scanning systems fail to properly scan full-width/half-width Unicode encoded HTTP traffic. By sending specially-crafted HTTP traffic to a vulnerable content scanning system, an attacker may be able to bypass that content scanning system.' A proof of concept affecting IIS is already being posted to security mailing lists. Cisco IPS and other IDS products are also affected." The CERT advisory lists 93 systems, with 6 reported as vulnerable (including 3com, Cisco, and Snort), 5 known not vulnerable (including Apple and HP), and the rest unknown.

marty writes "Februrary is not a good month for Mozilla developers. Infoworld reports about the efforts of Polish researcher Michael Zalewski, who apparently kept finding new vulnerabilities in the popular browser on a daily basis through the month, first postponing the 2.0.0.2 update, and then finding a remotely exploitable flaw in it immediately after its release."

nazarijo writes "The field of investigative forensics has seen a huge surge in interest lately, with many looking to study it because of shows like CSI or the increasing coverage of computer-related crimes. Some people see a career opportunity there, and are moving toward computer forensics, marrying both law enforcement and investigations with their interest in things digital. Central to this field is the study of data storage and recovery, which requires a deep knowledge of how filesystems work. Brian Carrier's new book File System Forensic Analysis covers this topic with clarity and an uncommon skill." Read on for the rest of Nazario's review. File System Forensic Analysis author Brian Carrier pages 600 publisher Addison Wesley Professional rating 9 reviewer Jose Nazario ISBN 0321268172 summary The standard for digital filesystem forensics

It's easy to think that computer filesystems are relatively simple things. After all, if 'dir' or 'ls' don't show what you're looking for, maybe an undelete program will work. Or will it? To be a decent, trustworthy expert in forensics (a requirement if you plan to participate in any criminal investigations), you'll have to learn how filesystems really operate, how tools like undelete and lazarus work, and how they can be defeated.

Carrier's book isn't a legal book at all, and it doesn't pretend to offer much insight into the law surrounding forensics. Instead it focuses on technical matters, and is sure to be the gold standard in its field. This is important, because it comes at you expecting you to have some knowledge, even if only informal, of what a filesystem contains. With a basic understanding of data structures, you'll get a wealth of information out of this book, and it will be a good reference long after you've first studied it.

File System Forensic Analysis is divided into three sections. These are arranged in the order that you'll want to study them to maximize the benefit you can hope to achieve, namely an understanding of how to examine filesystems for hidden or previously stored data. The first three chapters cover a fundamental series of topics: Digital Investigation Foundations, Computer Foundations, and an introduction to Hard Disk Data Acquisition. While they start at a basic level (e.g. what hexadecimal is), they quickly progress to more developed topics, such as the types of interfaces (SATA, SCSI, IDE), the relationship of the disk to the computer system as a whole, and how data is stored in a file and filesystem at a basic level. A lot of examples given use Linux, due to the raw, accessible nature of UNIX and UNIX-like systems, and the availability of tools like 'dd' to gather data.

Part 2 covers "Volume Analysis," or the organization of files into a storage system. This introduces the basics of things like partition tables (including how to read one). The next few chapters cover PC-based partitions (DOS and Apple), server-based partitions (BSD, Solaris and GPT partitions), and then multiple disk volumes like RAID and logical volumes. With this introduction, the final chapter of the section covers how to use these filesystem descriptions in practice to look for data during analysis. Filesystem layouts, organization, and things like journals and consistency checks are covered with a clarity and exactness that's refreshing for such a detailed topic.

Having covered the basics of filesystems, Part 3 covers the bulk of the book and material. Several chapters follow that specifically show you how to analyze particular filesystems by using their data structures to direct your reads. A range of filesystems are covered, including FAT, NTFS, EXT2 and EXT3, and the BSD types UFS1 and UFS2. Each filesystem has two chapters, one devoted to concepts and analysis, another entirely about data structures. Dividing each filesystem type like this lets Carrier focus first on the theory of each filesystem and its design, and then the practical use of its design to actually understand how to pull data off of it.

The real strength of File System Forensic Analysis lies in Carrier's direct and clear descriptions of the concepts, the completeness of his coverage, and the detail he provides. For example, a number of clear, well-ordered and simple diagrams are peppered throughout the book, explaining everything from allocation algorithms to NTFS alternative data streams. This use of simple diagrams makes the topics more easily understood, so the book's full value can be appreciated. This is the kind of thing that sets a book apart from its peers and makes it a valuable resource for a long time.

Finally, Carrier brings it all together and shows us how many aspects of filesystems can be examined using his "sleuth kit" tools, freely available and easy to use. Without appearing to hawk this tool at the expense of other valuable resources, you get to see how simple and direct filesystem manipulations can be done using a direct approach. This kind of presentation is what makes File System Forensic Analysis a great foundation.

Overall I'm pleased with File System Forensic Analysis, I think that Carrier has achieved what few technical authors do, namely a clear explanation of highly technical topics which retains a level of detail that makes it valuable for the long term. For anyone looking seriously at electronic forensics, this is a must have. I suspect people who are working on filesystem implementations will also want to study it for its practical information about NTFS. Overall, a great technical resource.

You can purchase File System Forensic Analysis from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

IE-less asks: "Can any Slashdot readers help me gather evidence to support the notion that developing an IE-specific WWW site is a bad thing? A state-level US-gov't organization we are contracted with (hence the anonymity) is about to embark on converting a Citrix-based application to a browser-based application, but in order to do so will make it IE Only. Our repeated screams of, 'No! Consider the standards!' have fallen on deaf ears. One of the few things we have found that helps is the Department of Homeland Security's recommendation that people switch browsers (look for 'Use another browser') care of the Get Firefox site. That's the sort of comment that makes people pay attention. The departments in question do not care about monopolies, non-Windows users, closed source expenses, etc. They will pay attention, though, to statements from powerful sources...such as the aforementioned. Anyone else find anything that works?"

maotx writes "Carnegie Mellon University is warning more than 5,000 students, employees and graduates that their Social Security numbers and other personal information may have been accessed during a breach of the school's computer network. What makes this one even more interesting compared to other recent break-ins is that CMU is home to the famous CERT."

nazarijo (Jose Nazario) writes "With regulatory compliance hanging over so many peoples' heads (GLBA, SOX, HIPAA, etc), information security and related fields have taken on a new twist in recent years. To that end, a number of people are looking at formal evaluation methods like OCTAVE to help guide them through the tricky world of audits. It's a sensible move, too, because you want something documented, thorough, and demonstrable when it comes to an audit, and preferably something objective. The book Managing Information Security Risks: The OCTAVE Approach by Christopher Alberts and Audrey Dorofee is intended to help you fill this need." Read on for the rest of Nazario's review. Managing Information Security Risks: The OCTAVE Approach author Christopher Alberts and Audrey Dorofee. pages 471 publisher Addison-Wesley Longman rating 5 reviewer Jose Nazario ISBN 0321118863 summary An introduction to information security risk management using the OCTAVE method

Authors Alberts and Dorofee are the principal developers of OCTAVE and are staff members at the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU), where CERT has offices. As such, they're the right people to describe OCTAVE. The CERT OCTAVE website area explains the process in more detail. Needless to say, OCTAVE is a very large, complex, heavy process for an organization to go through, with some arguable benefits. Very few organizations have done so to the best of my knowledge -- most of them are scared off by the complexity of the whole undertaking.

This brings up a very important point. It's important to state the difference between a critique of the OCTAVE method and the book itself. OCTAVE is interesting in that it's an attempt to formalize the complex process of information security evaluations. Despite its shortcomings and turnoffs, it has a purpose, and I wont dispute it for the most part. The book, instead, covers an abbreviated format of OCTAVE. It's important to focus on the strengths and weaknesses of the book and not the topic.

The books is organized into three main parts. Part 1 (covering chapters 1 and 2) is an introduction to the principles being discussed in the book. The method itself, and therefore these chapters, focus on a formal evaluation of information security risks and how to manage them. The principles focus on enumeration of assets, their threats and vulnerabilities, and then remediation of the threats to minimize the risk. The section introduces the core concepts to this philosophy.

Part 2 of the book, covering chapters 3 through 11, server two main purposes, preparation and then execution of the method. Chapter 3 introduces the fundamentals of the OCTAVE method, specifically how the three phases (asset-based threat profiles, vulnerability identification, and security strategy planning) fit together. The inputs of the method and its outputs are then described; you'll be using them in later chapters. Chapter 4 helps you prepare for the approach in your organization, including how important it is to get management buy-in, who will participate, and how to organize the evaluation. Project managers will adore this chapter.

The next few chapters cover the meat of the OCTAVE method. Chapter 5 covers processes 1 to 3, where assets are enumerated and the current state of the security profile is captured, as well. This step is crucial for building a baseline and knowing what you'll have to cover. Chapter 6 leads you through the threat profile, where you examine assets that you've identified as critical and the security requirements for them. And finally, in Chapter 7, the basic identification steps are done as you identify critical infrastructure components to examine later on. This is done so that you can work efficiently, as opposed to studying every asset in depth. By studying classes of assets you can (hopefully) achieve the same coverage without spending valuable time repeating the process.

Chapters 8 and 9 deal with the commonly understood parts, the actual vulnerability and risk analysis. Chapter 8 discusses vulnerability assessment tools and some basic questions to ask about them, but leaves the actual evaluation of those tools up to another text. Chapter 9 then helps you undertake the actual risk analysis, such as the impact of any threat being realized or the probability that one would be encountered. This is what most people think of when they think of an information security audit.

This gets to what is perhaps my biggest complaint about the book. It doesn't teach you how to think creatively about threats to information security. Instead, you're told to enumerate assets and threats against them via brainstorming, as though you'll somehow "get it" the first time (or every time). For someone new to the field, this can be hard, because not all assets are obvious -- and not all threats are understood. It's a hard skillset to teach, but it should have been attempted with more gusto.

Chapters 10 and 11 close the big circle of an information security audit, by developing an information security protection strategy. It's basically a series of outlines of meetings and their agendas as you present the findings of the evaluation but are (obviously) vague in the absence of any concrete findings.

This is probably a good time to raise another objection to this book. My second biggest complaint is that the authors never cut to the heart of what the OCTAVE method is trying to do. Sure, the book covers a stripped-down version of OCTAVE, but it doesn't ever get at how you can really adapt this to your organization. Instead, it's a series of rigid steps in the OCTAVE method. If you attempt to do something different for whatever reason, you're on your own. Again, an attempt to work in some flexibility beyond what is present in Chapter 12 (An Introduction to Tailoring OCTAVE, the start of part 3) would have been welcome. This chapter just keeps you inside the narrow confines of the OCTAVE approach.

Chapter 13 attempts to bring this home by discussing the practical applications for an organization. They attempt to discuss how a small company would utilize OCTAVE, but to be honest it's so heavy and time-consuming it's hard to see how they would employ anything but the barest of concepts to their workflow. Three other examples are given: a very large distributed organization, an integrated Web portal service provider (which faces unique threats), and large and small organizations. Again, while this chapter attempts to show how to tailor OCTAVE to anything but the largest and most diligently staffed of organizations, it falls to get to the salient points of the method. Instead, it tries to foist the process on them.

Finally, chapter 14 tries to bring it all home and discuss the information security life cycle of analysis, monitoring, control, and implementation (not in that order). They hope that OCTAVE has become a part of this process and show how it complements and matures this process. Instead, I wonder if an organization will think about the effort they just expended and be reluctant to do this again. The appendices are piles of worksheets, charts and workflows to go through with OCTAVE. You can make photocopies and use them if you implement the OCTAVE approach. It's very hard to take consider these methods strong enough when you read about the report card government agencies received for information security. While they may have not been following OCTAVE, it's hard to see how a book that so superficially treats the subject matter can help anyone do better. Almost everything is just a high-level line-item risk-and-mitigation strategy. Things like "Our organization cannot deliver effective or efficient health care without PIDS" and an impact of "High" are, to put it mildly, interesting in their superficiality. So many things are simply glossed over, yet so many worksheets remain. On the other hand, if a fair treatment of threats, assets, and the like were fully discussed the book would be many more volumes, a significantly more tedious tome, and too sensitive to the shifting sands of time.

Overall the book does a decent job of covering OCTAVE's core premises, but doesn't really provide much beyond that. It's a complex process that doesn't work well for a number of organizations. Instead of helping organizations see how to use it, the authors simply keep presenting OCTAVE for what it is, which makes me question the value of this book beyond someone who has already decided to implement OCTAVE. It doesn't seem like it has a lot to offer anyone who doesn't have a large body of knowledge in information security management and a staff to deploy with worksheets in hand. The book simply fails to contribute greatly beyond the very narrow specifics of OCTAVE.

You can purchase Managing Information Security Risks: The OCTAVE Approach from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Wapiti-eater writes "Released 7th April by the CERT Coordination Center, the Advanced Information Assurance Handbook looks to be a good general coverage, how-to type starting point (283 pages). 'This handbook (pdf) is for technical staff members charged with administering and securing information systems and networks.' Dealing primarily with Win2K and Redhat systems, it contains good information applicable to almost any public facing system."

Wapiti-eater writes "Released 7th April by the CERT Coordination Center, the Advanced Information Assurance Handbook looks to be a good general coverage, how-to type starting point (283 pages). 'This handbook (pdf) is for technical staff members charged with administering and securing information systems and networks.' Dealing primarily with Win2K and Redhat systems, it contains good information applicable to almost any public facing system."

An anonymous reader submits "The Software Sig Page encourages software maintainers to publish verifiable signatures for released software and to build the web of trust among software maintainers and software users. If you're afraid of downloading a trojaned OpenSSH, being 0wned while capturing packets, compiling an MTA as well as a backdoor on your system, not being able to trust tools you use every day, or never having a chance from the moment your OS boots, then you want some level of assurance that the software you use is everything the mainatainers expected you to have and no more. Look and check the MD5 and PGP signatures that come with software you download."

An anonymous reader submits "The Software Sig Page encourages software maintainers to publish verifiable signatures for released software and to build the web of trust among software maintainers and software users. If you're afraid of downloading a trojaned OpenSSH, being 0wned while capturing packets, compiling an MTA as well as a backdoor on your system, not being able to trust tools you use every day, or never having a chance from the moment your OS boots, then you want some level of assurance that the software you use is everything the mainatainers expected you to have and no more. Look and check the MD5 and PGP signatures that come with software you download."

LMCBoy writes "Steve Ballmer recently told an industry conference that Microsoft software is more secure than Linux. PJ at Groklaw has a nice, thorough analysis of this dubious claim. She points out that not only are there vastly more Microsoft exploits reported, but that the exploits tend to be much more severe, involving remote administrator access." In related news, mhesseltine writes "According to an article from the Washington Post, in an unusually ironic twist, Microsoft has started talking smack about their own products, instead of those of their competitors. Bill Gates said of Office 'it's too hard to find things in e-mail' and described some features of Word as 'clunky.'"

Slashback tonight brings you more on the recent cracking of GSM encryption,the odds of file sharers escaping industry scrutiny in Canada, the recently found (and stomped) OpenSSH bug, installation-time ads in Mandrake, and more. Read on below for the details.

Art of the Saber Jagaast writes "As a counterpoint to all the hype about the Star Wars kid, here's a Star Wars fan film that's actually very well done. Art of the Saber is 'a light saber fight sequence with the flavor of a Hong Kong martial arts action movie.' Well worth watching." Update by J : I've made torrents available.

Vote early, often, and reversably. An anonymous reader writes "As a follow up to a previous story here on Slashdot on electronic voting, Excite has a story on the same subject with a bit more information including this amazing quote from Deborah Seiler, Diebold's West Coast sales representative: '"These activists don't understand what they're looking at," Seiler said.'"

GSM-crack paper online morcheeba writes "Copies of the GSM-crack paper described in last week's Slashdot article are now available online (PDF) thanks to John Young's Cryptome"

Mandrake ads...take 2 *no comment* writes "Apparently there has been some controversy over the ads in the upcoming Mandrake 9.2. I thought it was pretty cut & dried, but apparently Mandrake thought it was enough of a controversy to to release a written statement about it. I wonder how many flames were posted in the slashdot forum using the download version of Opera."

Blaster Worm still alive and well on MIT campus fwc writes "MIT still has 900 network drops disabled due to the Blaster worm infection. Of particular interest is that MIT network security requires users to reformat their hard drive and re-install their operating system before they get back on the network. Sounds like a good excuse to reinstall something other than a Microsoft operating system."

A big AWOOOGAH for Canadian file sharers. Rumor writes in response to a recent story suggesting that Canadian users could swap files scot-free: "Listen, Canadians, don't go using your p2p apps and thinking you are immune from lawsuit, you are liable for copyright infringement if you share files on p2p apps.

To wit: a fellow law student and I have written an analysis of s. 80 of the Copyright Act and we've concluded that one can download music safely under the Private Copying provision, but no one can share or upload files without infringing on copyright.

In a nutshell, Private Copying allows anyone to make a copy of a song purely for their own use. As you probably know, when you share files and someone downloads from you, what actually happens is that their computer makes a request and your computer actually sends the file to them. Thus, you're copying for someone else's use and infringing. It doesn't matter if you didn't realize that's what happens, either... intent is not required for infringement.

The upside is that you can accept copies from other people (ie. download) all you want. Although there might be an issue of contributory infringement to worry about... I won't go into analyzing that, since so far the record companies are only suing uploaders.

The article can be found on greplaw.

I've recently confirmed this analysis with an IP law professor at my university, so I'm pretty damn sure of it. So, please, be aware of this danger. Downloading cool, uploading/sharing not. I guess the situation still better than nothing."

Why not ask for your money back? zaaj writes "There are several articles out about a newly found/fixed(openssh.org) buffer management bug in OpenSSH and some derivatives. Cisco's Advisory only mentions DoS attacks against certain of their SSH-enabled devices, but ZDNet's article hints at rumors of long-existing root exploits. Regardless, RedHat's got their typical list of updated packages with the patch back-ported. A few other distro's have info in the vendor section of Cert's advisory CA-2003-24"

Sgt York writes "In a NYT article (republished in the Houston Chronicle, no subscription required) experts at CERT, F-secure, Trusecure, and the Hall of Justice (see article) think that SoBig.F is a spam scheme in the making. They say that SoBig.F is the 6th variant in an ongoing experiment with the possible goal of setting up a distributed spam network, to be rented out to the highest bidder. If that is their goal, they are well on their way. Another disturbing note in the article is that "In the case of four of the six programs, a new version was launched immediately after the self-timed expiration date of the preceding one". SoBig.F expires in two weeks. "

BSD Forums writes "On March 3rd, 2003, Internet Security Systems, in cooperation with the Department of Homeland Security, issued a warning regarding a hole found in Sendmail. The warning, echoed by CERT, warned system admins that any version lower than 8.12.8 was vulnerable to a serious root exploit. Sendmail has a long history of security holes, most of which have been thoroughly documented on security sites. While Sendmail runs half the mail servers in the world, there are smaller and easier-to-use mail transfer agents (MTAs). Network administrator Glenn Graham demonstrates how Postfix gives you most of the power with a fraction of the pain."

GNUman writes "Cisco's IOS vulnerability, posted by Slashdot and CERT, has now a published exploit available, as reported recently by CERT. While there are some some articles claiming that the Internet survived a major flaw, maybe with a publicly available exploit could script kiddies start creating havock?. jerw134 wanted to start a pool to find out when the exploit would be publicly available, here's the answer."

GNUman writes "Cisco's IOS vulnerability, posted by Slashdot and CERT, has now a published exploit available, as reported recently by CERT. While there are some some articles claiming that the Internet survived a major flaw, maybe with a publicly available exploit could script kiddies start creating havock?. jerw134 wanted to start a pool to find out when the exploit would be publicly available, here's the answer."

GNUman writes "Cisco's IOS vulnerability, posted by Slashdot and CERT, has now a published exploit available, as reported recently by CERT. While there are some some articles claiming that the Internet survived a major flaw, maybe with a publicly available exploit could script kiddies start creating havock?. jerw134 wanted to start a pool to find out when the exploit would be publicly available, here's the answer."

Joff_NZ writes "CERT has released an advisory regarding a serious flaw in all Cisco routers and switches which run IOS and process IPv4 packets (i.e. pretty much everything), which causes the device to stop processing inbound packets, and so: 'The device must be rebooted to clear the input queue on the interface, and will not reload without user intervention.' There are apparently no known exploits (yet), and Cisco have this advisory with a workaround and available fixes."

evenprime writes "In 2001, Dmitry Sklyarov described vulnerabilities in Adobe Acrobat and Adobe Acrobat Reader while giving a talk at Defcon 9. As has been previously mentioned, Dmitry was arrested the day after this talk. He and his company Elcomsoft were charged with violating the DMCA. Now Elcomsoft have announced that Adobe, two years later, has still not patched these bugs."

You asked nmap creator Fyodor many excellent questions, and his answers (below) are just as excellent. You'll want to set aside significant time to read and digest this interview, because Fyodor didn't just toss off a few words, but put some real time and energy into his answers.

1) Interesting stories involving nmap?
by Neologic

Nmap has obviously become a huge success in the *nix world. I would wager that practically all sysadmins and security folk use nmap. With this sort of use by such creative and lazy people, there must have been some interesting stories involving nmap, perhaps unusual uses of it, or funny anecdotes. Are there any you would like to share?

Fyodor

The coolest use ever was undoubtedly when Trinity used it to try and save the human race :). But the use I find most gratifying are the Chinese students and residents who have written me about how they use Nmap to locate open proxies. These proxies allow for surfing the uncensored Internet, including the news, educational, pornographic, religious, open source software, government, political, search engine, and human rights sites that are blocked by the Great Firewall of China.

Many of the best features in Nmap came from the user community in ideas if not implementation. For example, the protocol scan (-sO) determines what IP protocols (TCP, UDP, GRE, etc.) a host is listening for. I had not thought of this, but the idea and patch came out of the blue one day in an email from Gerhard Rieger. On another day, a guy named Saurik sent a patch called Nmap+V that allows Nmap to do basic service/version fingerprinting against open ports. It has attracted a cult following, and I plan to add similar functionality to Nmap this year. The initial Windows port by eEye arrived similarly. Despite all these great suggestions, certain other user-contributed ideas are not on the agenda.

Then there are a small handful of users who detect problems nobody else would ever notice, like 4 byte/host memory leaks. They send me error messages with notes saying the bug happens "about once per 700,000 IPs". I have no idea what these guys are up to, but some have been sending me this kind of mail for years. They can't be spammers, as they are intelligent and also use more sophisticated scan techniques than you would need to just find SMTP servers.

2) Recent increases in anal-retentiveness...?
by Zeriel

There's been a marked increase in system administrators thinking that anything even remotely resembling a network scan is eeeeevil (case in point, last year I almost got kicked out of college for scanning port 80 on my dorm subnet looking for interesting websites to read)...

What do you think can be done to make scanning IP addresses/ports have less of a negative stigma? This is in the same sort of category as legit vs. illegit uses of anything else (P2P, whatever)--what's the rationale for punishing something that could maybe lead to criminal activity, and how can we make network scanning tools have practical uses again?

Fyodor

That is an excellent question, and one that concerns me as well. But first, I think your final statement is too extreme. I would guess 90% of network scanning is non-controversial. You will rarely be badgered for scanning your own machine or the networks you administer. The controversy comes when scanning other networks. There are a lot of (good and bad) reasons for doing this sort of network exploration. Perhaps you are scanning the other systems in your {dorm, department, cable LAN, conference LAN} to look for publicly shared files (FTP, SMB, WWW, etc.). Or perhaps your just trying to find the IP of a certain printer. Maybe you scanned your favorite web site to see if they are offering any other services, or because you are curious what OS they run. Perhaps you are just trying to test connectivity, or maybe you wanted to do a quick security sanity-check before handing off your credit card details to that ecommerce company. You might be conducting Internet research, or be bored on a rainy afternoon. Or are you conducting reconnaissance in preparation for a breakin attempt?

The remote administrators rarely know your true intentions, and do sometimes get suspicious. The best approach is to get permission first. I've seen a few people with non-administrative roles land in hot water after deciding to "prove" network insecurity by launching an intrusive scan of the entire company or campus. Admins tend to be more cooperative when asked in advance than when woken up at 3AM by an IDS alarm claiming they are under massive attack.

You compared Nmap to P2P tools in having a "negative stigma". In both cases, one effective way to fight the stigma is to limit your own use to "legitimate" purposes. Use BitTorrent to download RedHat ISOs, but not Matrix Reloaded. Use Nmap to secure and monitor your computers, but not to attack other networks. And if you decide to attack other networks anyway, please be courteous and set the evil bit.

Now I'll admit that I don't always obtain explicit permission before scanning other networks. I don't believe (but IANAL) that a simple port/OS scan of a remote system is or should be illegal. Any machine connected to the Internet will be scanned so often that most admins ignore such "white noise" anyhow. But scan other networks often enough, and someone will eventually complain. So my advice would be:

1. Don't do anything controversial from your work or school connections. Even though your intentions may be good, you have too much to lose if someone in power (boss, dean) decides you are a malicious cracker. Do you really want to explain your actions to someone who may not even understand the terms "port scanner" or "packet"? Spend $10 bucks a month for a dialup or shell account. You didn't really violate this rule, as scanning your dorm subnet for just port 80 should not even be remotely controversial!
2. Target your scan as tightly as possible. If you are only looking for web servers, specify -p80 rather than scanning all 65,535 TCP ports on each machine. If you are only trying to find available hosts, do an Nmap ping scan. Don't scan a /16 when a /24 will suffice. The random scan mode now takes an argument specifying the number of hosts, rather than running forever. So consider -iR 1000 rather than -iR 10000 if the former is sufficient. Use the default timing (or even "-T Polite") rather than "-T Insane".
3. Nmap offers many options for stealthy scans, including source-IP spoofing, decoy scanning, and the more recent Idle Scan technique. But remember there is always a trade-off. You will be harder to detect if you launch scans from an open WAP far from your house, with 17 decoys, while doing followup probes through a chain of 9 open proxies. But if anyone (such as Tsutomu Shimomura) does track you down, they will be mighty suspicious of your intentions.

I occasionally consider adding some sort of "notification packet" prior to a scan that would give hosts the chance to respond and opt-out. This would be like the /robots.txt directives currently used to control polite Web robots. Perhaps the format could even include a text string that IDS systems could log, like: nmap -sS -p- -O -m "Direct questions about this scan to ops at x3512" 192.168.0.0/16 nmap -sS -p- -O -m "mY n4m3 iZ Zer0 |<00L and I'll 0wn j0o%#@" targetcompany.com/24 Of course Nmap would have an option to omit the notification or to send it and ignore any negative responses. Some scanners, such as ISS Internet Scanner already send out NetBIOS popup messages to scanned hosts by default, and other scanners use syslog. I won't be adding any features like this to Nmap unless I see substantial demand and the obvious issues are worked out.

3) OS fingerprinting
by neoThoth

What are the latest advances in fingerprinting networked devices that seem most promising to you? I have started reading papers on HTTP fingerprinting and such and wonder how these will figure into the NMAP architecture. What are the most elusive OS's that aren't on the NMAP OS fingerprint database?

Fyodor

There are a number of OS detection techniques I hope to add this year. One is to guess (or calculate) the initial TTL of response packets, since this varies by OS. Some operating systems also "reflect" your own chosen TTL under various circumstances. Then there are some newer TCP options, such as selective ack that I might test for. Explicit Congestion Notification (RFC 2481/3168) also shows promise. I'll probably add all of these at once later this year, after discussions with the Nmap-dev list. If you wish to participate, you can join that list by sending a blank email to nmap-dev-subscribe@insecure.org. There is also a low volume, moderated list for announcements about Nmap, Insecure.org, and related projects. You can join the 15,000 current members by mailing nmap-hackers-subscribe@insecure.org [archives].

While adding new fingerprinting techniques is fun and exciting, improving the signature database often ads more value. The DB now contains more than 850 signatures, from the Acorn RISC OS and Aironet wireless LAN bridge to the ZoomAir wireless gateway and Zyxel Prestige routers. We're talking gaming consoles, phones, PBX systems, PDAs, webcams, networked power switches, you name it! New fingerprints are submitted daily.

Application level fingerprinting (including HTTP) is coming. I usually regret stating dates, but I hope to develop this functionality within the next 3 months.

4) Stepping into a network security career
by Anonymous Coward

I'll be graduating this month with a shiny new BS in Computer Science. I've done plenty of Unix sysadmin work throughout college and even deployed some high-interaction honeynets. I'm very interested in network security and systems programming. Do you have any advice for people in my situation who want to head into a career in network security?

Fyodor

Congratulations on your graduation! Unfortunately (for newcomers), the security field is one that often expects substantial experience and references. This is partly because these jobs require extraordinary trust, and also because of an aversion to mistakes. Everyone makes mistakes, but they can be extraordinarily costly in security and neophytes tend to make more of them. But don't lose hope! Talented security minds are still in very high demand, just be aware that you will have to work even harder to prove yourself.

Here are my suggestions for anyone starting out in network security, whether for fun or profit:

Step 1: Learn everything you can

1. You may wish to start with reading a general overview of security, such as Practical Unix and Internet Security 3rd Edition.
2. Reading alone won't teach you much. Hands-on experience is critical, so I would set up at least a basic test network. At the very minimum you should have a Unix box or two and a Windows machine (because these are very common in the real world). You can use very cheap machines, or even emulate a large network with virtualization software such as VMWare.
3. Next you should learn more about how attacks are performed. Take a look at the excellent and free Open Source Security Testing Methodology Manual (OSSTMM). This document aims to provide a comprehensive framework for security testing. But it mostly lists tasks to perform, without specifying how to do so. You will gain a lot from this manual if you research the tasks you don't know how to complete, and if you actually try performing the tasks on your test network. If this manual is too curt or hard to follow, you could try a more verbose book on vulnerability assessment, such as Hacking Exposed 4th Edition.
4. Now that you understand many of the general security ideas, it is time to get current. This is one area that has actually become easier in the last decade. The thinking used to be that vulnerability information should only be distributed to well-known and trusted administrators and security researchers through private digests such as Zardoz. This was a disaster for many reasons, and the full disclosure movement was born. In the last couple of years things have started to shift toward more limited ("responsible") disclosure and there is also a disturbing pay-money-for-early-disclosure trend. But information is still much more available than it used to be. Most of the news is carried on mailing lists, and I archive the ones I consider the best at Lists.Insecure.Org. You must subscribe to Bugtraq, and I would also highly recommend pen-test, vuln-dev, and security-basics. Read at least the last 6-12 months of archives. Choose other lists that correspond to your interests. SecurityFocus also offers a security-jobs list which is an excellent resource for finding jobs or just understanding what employers desire.

   There are two major reasons for reading Bugtraq. One is that you must react quickly to new vulnerabilities by patching your servers, notifying your clients, etc. You can get this by simply scanning the subject lines or advisory summaries for bugs that directly apply to you. But then you will miss out on another crucial purpose of Bugtraq. Actually understanding a vulnerability helps you defend against it, exploit it, and identify/prevent similar bugs in the future. When you are lucky, the advisory itself will provide full details on the bug. Check out this excellent recent advisory by Core Security Technologies. Note how they describe exactly how the Snort TCP Stream Reassembly vulnerability works in detail and even include a proof-of-concept demonstration. Unfortunately, not all advisories are so forthcoming. For bugs in Open Source software, you can understand the problem by reading the diff. The next step is to actually write and test an exploit. I would recommend writing at least one for each general class of bug (buffer overflow, format string, SQL injection, etc.) or whenever a bug is particularly interesting.

   Be sure to read the latest issues of Phrack and the research papers posted to the mailing lists. Send your comments and questions to the authors and you may start interesting discussions. Read well-regarded books on the security topics that interest you most.

   I can't emphasize enough that you should intersperse hands-on work with all of this reading. Install unpatched RedHat 8 (or whatever) and run Nmap and Nessus against it. Then compromise it remotely, maybe via the latest Samba hole. Start out with a prewritten exploit from Bugtraq, which isn't quite as easy as it sounds. You may have to modify the 'sploit to compile, brute force the proper offset, etc. Then break in again using a different technique, and your own exploit. Install Ethereal and/or tcpdump and ensure you understand the traffic on your network during both your exploitation and normal network activity. Install Snort on an Internet-facing machine and watch the attacks and probes you'll experience. Wander around your neighborhood with Kismet, Netstumbler, or Wellenreiter on your Laptop or PDA to look for open WAPs. Install DSniff and execute an active MITM attack on an SSH or SSL connection between two of your computers. Take a look at my Top 75 Tools List and ensure you understand what each does and when it would be useful. Try out as many as you can.

5. Take a vacation, or at least a weekend camping! You deserve it! The steps above would probably take at least 3-12 months full-time, depending on your motivation level and the depth and breadth of your research.

Step 2: Now apply your newfound knowledge

Now you have learned enough to be dangerous. At this point, you would have little trouble obtaining most certifications, after studying the specifics of each topic. If your main goal is to find a job quickly, perhaps adding these extra feathers to your cap might be worthwhile. But I think your best bet is to prove your knowledge by joining and contributing to the security community. While this does indeed help others, it isn't an entirely selfless act. It improves your skills, leads to important contacts, and demonstrates your knowledge and ability in a constructive way. The latter is important if securing a career is one of your goals. These steps should also be fun! If not, perhaps you should keep looking at other fields. Here are some ideas:

Start participating with insightful comment and answers on the mailing lists. This is very easy and serves as a great learning experience, way to meet people, and garners some name recognition. If a security manager with a stack of 60 resumes recognizes your name, that is a huge win!

When a new worm or a big new vulnerability comes out, everyone wants to know the details. If you stay up all night disassembling the worm/patch and write the first comprehensive analysis, many folks will find that valuable. And you will learn a lot. Let your first priority be quality - if someone beats you to it, just compare your results with theirs to see if you (or they) missed (or misinterpreted) anything. You can also post your own exploits, although that is more of a political hot potato.

Attending security conferences is a great way to learn, party with fellow hackers, and network (in every sense of the word). Much better is to speak at these conferences. This field changes rapidly so there are always new topics and technologies to discuss. You don't have to be a well-known expert with a long history - just learn your topic well and put in the effort for a quality presentation. You could present at Defcon, at one of the more commercial events, or at a smaller regional con like ToorCon, CodeCon, Hivercon, etc. Among other advantages (often free admission/travel/hotel), this is a great way to meet people with similar interests. I spoke at the latest CanSecWest and have submitted a proposal for the next Defcon.

Now that you've seen and understand a wide variety of software vulnerabilities from your Bugtraq research, start finding your own. You can start by downloading any PHP app from Sourceforge. Most of those are hopelessly vulnerable to Cross-Site-Scripting, SQL injection, and/or remote code execution by "remote include" directives. Many (if not most) Windows shareware daemons are also vulnerable to simple buffer overflows and format-string bugs. Notify the authors and then write an advisory. After a few of these "easy targets", try breaking some more widely deployed programs.

Write a security tool! I could list some suggestions, but by this point you will have many of your own ideas as to what is needed. Scratch an itch.

I hope this helps. If you want more suggestions, Ask Slashdot. From that story, I found this post particularly insightful, especially the emphasis on "people skills". I don't claim to have any, but understand the value :).

5) Have you ever been tempted to use your gifts...
by Tim_F

...in a negative manner?

Have you ever hacked into someone else's computer? Have you ever considered it? What would cause you to think of doing this? Would your tools (nmap, etc.) be enough to allow you to do this?

And if you haven't, why is that the case?

Fyodor

I never do script-kiddie style "hack any random vulnerable box on the Internet" cracking. But sometimes I will launch targeted attacks at specific companies. I'll usually start with just a web browser and various search engines to learn everything I can about my target. I need to understand what the company does, who it partners with, and whether it has any corporate siblings, subsidiaries, or parents. Beyond that, posts by individual employees can be a gold mine. Besides providing names and titles for social engineering and brute force password attacks, the IPs in the mail/news routing headers can be very valuable. One of the reasons I run my own mailing list archive is to maintain access to the raw mail folders which contain the routing info and X-no-archive posts that web archives strip out. Another advantage to locating employees is that you can send them trojan executable attachments, which can be a very effective way into the network.

Next I'll gather known IP network information on the companies via DNS, whois, regional registries like ARIN, routing info, Netcraft, etc. Then comes the scanning (I tend to use Nmap), application-probing, vulnerability discovery, and exploitation stages.

Of course, I only do this when the company is paying me to do so. Performing these pen-tests offers several advantages over blackhat activity:

1. You don't go to jail (If you've worded your contract carefully.)
2. Instead of having to keep your übertechniques secret to avoid prosecution, you get to demonstrate them to management.
3. They actually pay you for this! And you are helping to protect them and the privacy of their customers.

Now some people might ask how you gain these skills without practicing on other networks first. Cheap hardware and the evolution of free UNIX operating systems have made this much easier than in the past. See the previous answer for some suggestions. And remember that you can always work together with friends, or participate in hacking contests like Defcon's Capture the Flag.

6) You'll have seen a lot of breakins.
by Hulver

During your time running Honeypots, you'll have seen a lot of compromised systems. Is there any incident that's really stuck in your mind because of the audacity of the attempt, or the stupidity of the person attempting the breakin.

Fyodor

On the humorous front, one attacker was was running a public webcam during his exploits, so we were able to watch him crack into our boxes in real time :). I will resist the urge to link a screenshot. His rough location was determined when we noticed Mrs. Doubtfire playing on his TV and correlated that with public schedule listings. He was working with a Pakistani group, but was actually on the US East Coast.

In the "disturbing audacity" front, this year we found that a group of crackers had broken into an ecommerce site and actually programmed an automated billing-sytem-to-IRC gateway. They could obtain or validate credit card numbers by simply querying the channel bot! Expect a more detailed writeup soon.

7) What makes a honey net enticing?
by cornice

It seems that many of the honey nets that the average hobbyist would run are built to attract a lesser cracker. What I mean is that ports are left open that normally would not be left open. Services are running that normally should not, etc. I think that a really smart fish would see this as nothing but a cheap lure and refuse the bait. Do you think it's possible to fool the really smart fish? Is is possible to bait with something enticing enough without tipping off the big fish? Does publication of your work make this task more difficult?

Fyodor

Excellent question, and I had many of the same concerns upon joining the project. Then I remembered that most of the attacks and real-world compromises are committed by these marginally skilled script kiddies. So there is still a lot of value in understanding their tools, tactics, and motives. Despite this apparent limitation, I have been surprised by some of the sophisticated things we have found. For example, the first known "in the wild" attack using the Solaris dtspcd vulnerability was caught by one of our honeynets and resulted in this CERT advisory. Then one of our Honeynet Alliance members had their Win2K honeypot compromised and joined into a botnet with 18,000 machines! Attackers on such a grand scale won't even know all of the companies they have compromised, much less whether any of the systems are honeynets.

I do believe baiting the "smart fish" might be possible, but I have never done this. Is not legally entrapment, as we aren't any sort of police force, but I am not very comfortable with the idea. If someone attacks my box that is just unobtrusively sitting on the network, I believe the attacker should have no expectation of privacy for his activities on the system. Things become more complex if I try to lure the attacker.

8) IPv6
by caluml

Do you think that with the very large address space of IPv6 that random scanning for a certain port will die off? (I notice nmap doesn't support random IPv6 address scanning - maybe you've already come to the same conclusion?) Simply put, the chances of finding a machine if it's not advertised anywhere will be very much reduced. Will this make people lazy and complacent, trusting on the large numbers involved to protect them?

Fyodor

Finding a machine by by pinging a completely random 128-bit address will probably never be effective. Fortunately, we won't have to! Nmap does not even do that for 32-bit IPv4 addresses - it is smart enough to skip huge blocks of address space that are unallocated or used for private (RFC1918, localhost) addresses. We will also see patterns emerge for IPv6. For example, they may often be allocated sequentially so that finding one leads to many others. I am waiting until adoption rises and we start seeing these patterns emerge before I can implement them appropriately in Nmap. Certain new DNS features may also prove useful for locating IPv6 machines and networks.

9) standalones and small home nets
by zogger

it seems like most of the emphasis is on enterprise networks, but that still leaves millions and millions of home machines and small home networks just stuck. What do you see as some of the trends and solutions for those people? Their data and system integrity is just as important to them as any corporations is, and usually not having the appropriate skill set, is even harder to implement.

Fyodor

I am afraid the focus by security companies on enterprise networks will continue, as that is where the money is. The good news is that securing small home networks is far easier. But that doesn't make it simple, nor mean that many people will bother. I would categorize the risks into 3 categories:

Traditional network server vulnerabilities: Your average home user doesn't need to run any network daemons or have any TCP/UDP ports open to the Internet. Most of the time they only have 1 IP, used either by a standalone PC or a NAT device (e.g. "broadband router") in front of their small network. This is a good configuration, as it limits what attackers can reach directly. But you need to be sure that the IP doesn't have any unnecessary ports open. You can verify this by running 'netstat' on the Windows or UNIX machine using the IP. I would also recommend confirming using a port scanner such as Nmap. Here are example commands:

nmap -p- -sS -T4 -v -O [your IP]
nmap -p- -sU -v [ your IP ]

The TCP and UDP scans could be combined into one execution, but are listed separately since the TCP scan may go much faster. Remote UDP scans are also less reliable against some heavily filtered hosts. You may have to rely on the netstat info or configuration details in this case.

Any open ports found should be evaluated with extreme prejudice. Unless clearly necessary, close Windows file sharing, external NAT device admin ports, and everything else found.

Don't forget the wireless backdoor! Blocking the Internet link from your private machines is insufficient if anyone can hop on your open WLAN and attack your machines. WEP isn't perfect, but the 104-bit (so-called 128-bit) version should at least keep people from accidentally connecting to your network or sniffing your data. Be sure to set a good password and upgrade to recent firmware for your WAP and other network devices.

Subscribe to the security advisory lists for all the operating systems (and devices, if available) you run. Major vendors such as RedHat, Debian, FreeBSD, Mandrake, and Microsoft all offer these. Most even offer automatic updates if you desire that.

Client vulnerabilities: Once you close the services you don't need (ideally all of them), client vulnerabilities must be addressed. Keeping your web browser and mail reader up-to-date is particularly crucial. Also harden them as much as possible. For example, IE is full of holes but at least has a good interface for site-by-site security policies (Tools -> Internet Options -> Security). Go through and neuter the "Internet zone" settings by disabling ActiveX and Java. In the rare case that sites need this, find an alternative site or add them to the trusted zone. If your are really serious about security, neuter "trusted sites" and "local intranet" privileges as well. Many recent IE vulnerabilities trick the browser into using the wrong zones. Consider using a different browser. Also configure your mailer to disregard HTML and JavaScript.

Remember to pay careful attention to security warnings, whether they come from IE, Mozilla, your ssh client, or anything else. Don't just click OK. And don't shoot yourself in the foot when configuring your apps. It is hard to entirely blame the vendor when users tell P2P apps or Windows filesharing to share their whole drive without any password. Failing to change default passwords or enable basic restrictions on X Window or FTP servers is only slightly more forgivable. All of these errors happen frequently! The apps/devices should be secure by default, but you have the ultimate responsibility for protecting your data.

Malware: This is what I consider the biggest problem on desktops: people running applications they can't trust. Email borne viruses, worms and trojans are an obvious example. Be very careful what you click on. Unfortunately, it is very difficult to know what to trust. Mail is trivial to forge, and even the "proper" installers for many P2P applications infest your computer with loads of invasive spyware. Even Intuit TurboTax was caught writing to customers' boot information track.

What can you do? My honest suggestion is to run peer-reviewed open source applications on a free OS such as Linux or FreeBSD. You still have to be careful, but these problems are far less prevalent on UNIX platforms, which also have better tools and procedures to deal with them.

What if dumping Windows is not an option? Run NT/2K/XP instead of Win9X/ME, and try to run everything you can as an unprivileged (non-administrator) user. Be extraordinarily careful about what you install and run, and make frequent backups. You might also want to look into a personal firewall such as Zone Alarm (limited free version.

10) What is your favourite tool?
by Noryungi

I have just read your top 75 security tools list. Thank you for posting all this information, which I am going to study very carefully.

One question though: in all these tools, which one is your personal favourite? (This excludes Nmap, of course).

Fyodor

I have far too many favorites among this great group to choose just one! But here are a few developers and tools that are particularly worthy of mention:

One of the people I most admire in the security field is Solar Designer. He is a guru in networking, security, and low level kernel/assembly/architecture details. He has also created many tools that security professionals use daily. Yet he never exhibits the arrogance, elitism, and egotism that sadly characterizes so many "stars" of the security community.

Among SD's tools is John the Ripper, my longtime favorite local password hash cracker. It has been around forever, but was written with a flexible and powerful interface while keeping extensibility in mind. So it is still as useful in these days of shadowed password files and MD5/Blowfish hashes as it was back in the days of crypt() and unprotected /etc/passwd. Lately SD has been working on the Owl secure GNU/Linux distribution, which can be installed on disk for hardened systems like firewalls, or booted and run from CD as an easy way to run security tools such as John and Nmap.

Another of those "brilliant yet still nice" security developers is Dug Song. Even after the seminal "Insertion, Evasion, and Denial of Service" paper by Ptacek and Newsham, many IDS vendors continued to ignore the problem. When Doug released Fragrouter (now fragroute), which implements some of these attacks, vendors finally took notice! He has also written the excellent libdnet library, but my favorite of his tools is DSniff, a suite of tools for advanced network sniffing and "monkey-in-the-middle" attacks. It even handles ARP poisoning and other techniques for sniffing hosts on a switched LAN.

While I'm on this topic, let me also give "mad props" to the Hping2 packet prober, Kismet wireless stumbler, Ethereal packet decoder, Netcat, recent THC releases, Snort IDS, the Nessus vulnerability scanner, and all the other great Open Source tools out there!

I would also like to thank Slashdot for granting me this interview and to everyone who asked such excellent questions. I only wish I had time to answer more of them. Then again, I have probably rambled on enough. Now it is your turn to ramble in the comments :).

Cheers,
Fyodor

bahamutirc writes "Yet another security problem was discovered by Michal Zalewski in Sendmail 8.12.8, 'a buffer overflow in address parsing due to a char to int conversion problem which is potentially remotely exploitable.' Apparently somebody jumped the gun and posted before Sendmail had a chance to notify anyone, so they had to release it today. Go grab your source." Here's the CERT advisory.