Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Submission + - Book review: Designing and Building a Security Operations Center

benrothke writes: Title:Designing and Building a Security Operations Center

Author: David Nathans

Pages: 276

Publisher: Syngress

Rating: 8/10

Reviewer: Ben Rothke

ISBN: 978-0128008997

Summary: Good introduction to those looking to build their own security operations center





Many organizations are overwhelmed by the onslaught of security data from disparate systems, platforms and applications. They have numerous point solutions (anti-virus, firewalls, IDS/IPS, ERP, access control, IdM, single sign-on, etc.) that can create millions of daily log messages. In addition to directed attacks becoming more frequent and sophisticated, there are regulatory compliance issues that place increasing burden on security, systems and network administrators.



This creates a large amount of information and log data without a formal mechanism to deal with it. This has led to many organizations creating a security operations center (SOC). A SOC in its most basic form is the centralized team that deals with information security incidents and related issues.



In Designing and Building a Security Operations Center, author David Nathans provides the basics on how that can be done. An effective SOC provides the benefit of speed of response time to a security incident. Be it a DDoS attack or malware which can spread throughout a corporate network in minutes, and potentially knock out the network, every second counts in identifying these attacks and negating them before they can cause additional damage. Having a responsive SOC can make all the difference in how a firms deals with these security issues.



The book notes that the SOC is akin to an enterprise nervous systemthat can gather and normalize vast amounts of log and related data. This can provide continuous prevention, protection and detection by providing response capabilities against threats, remotely exploitable vulnerabilities and real-time incidents on the monitored network.



The books 11 chapters provide a start for anyone considering building out their own SOC. Topics include required infrastructure, organizational structure, staffing and daily operations, to training, metrics, outsourcing and more.



When building a SOC, the choices are for the most part doing it yourself (DIY) or using an outsourced managed security service provider (MSSP). The book focuses primarily on the DIY approach, while chapter 10 briefly details the issues and benefits of using a MSSP. The book provides the pros and cons of each approach. Some firms have a hybrid approach where they perform some SOC activities and outsource others. But the book doesn't details that approach.



The book provides a large amount of details on the many tasks needed to create an internal SOC. The truth is that many firms simply don't have the staff and budget needed to support an internal SOC. They also don't have the budget for an MSSP. With that, Mike Rothman of Securosis noted that these firms are "trapped on the hamster wheel of pain, reacting without sufficient visibility, but without time to invest in gaining that much-needed visibility into threats without diving deep into raw log files".



One important topic the book does not cover is around SIM/SIEM/SEM software. SIEM software can provide a firm with real-time analysis of security alerts generated by network and security hardware, software and other applications.



Many benefits come from an effective SIEM tool being the backbone of the SOC. A SIEM tool consolidates all data and analyzes it intelligently and provides visualization into the environment. But selecting the appropriate SIEM and correctly deploying it is not a trivial endeavor.



Those looking for a good reference on SIEM should read: Security Information and Event Management (SIEM) Implementation, which I reviewed on Slashdot - http://books.slashdot.org/story/11/02/23/1328243/book-review-security-information-and-event-management-implementation. That book does provide an excellent overview of the topic and will be of value to those reading looking for answer around SIEM. Those looking for a solid introduction to the world of SIEM should definitely get a copy.



The book notes that the most important part of a SOC, and often the most overlooked, is that of the SOC analyst. And with that, the book writes how it's important to be cognizant of the fact of SOC analyst burnout. SOC analysts can burnout and it's important for an organization to have a plan to address this, including aspects of training, management opportunities and job rotation.



Building an in-house SOC takes significant planning an attention to detail and the book details a lot of the particulars that are required for an effective SOC design.



The implementation of a SOC will cost a significant amount of money and management will often want to have metrics to let them know what the SOC is doing. The book spends a brief amount of time on SOC metrics; which is a topic that warrants a book in its own right. There are many metrics that can be created to measure SOC efficacy. Effective SOC metrics will measure how quickly incidents are handled by the SOC, and how incident are identified, addressed and handled.



The downside to metrics is that they must be used judiciously. It's important not to measure base performance of a SOC analyst simply on the number of events analyzed or recommendations written. Metrics used in that manner are akin to help desk where analysts are only concerned about getting calls finished, in order to meet their calls completed metrics.



As important as a SOC is, this is surprisingly the first book written on the topic. At under 250 pages, the book provides an introduction to the topic, but is not a comprehensive work on the topic. There are areas in SOC management that the book doesn't cover, such as SOC documentation, creating and using SOC operation run books, and more.



But even with those missing areas, Designing and Building a Security Operations Centeris a good reference to start with. A SOC is a security component most organizations are in dire need of, and the book is a good way to get them started on that effort.





Reviewed by Ben Rothke

Comment Re:So... did he have any tested? (Score 3, Insightful) 82

Krebs writes that he had people at The University of Alabama at Birmingham ready to do the testing. But they couldn’t get the necessary sign off, both from the school administration and the FDA.

And even if they did, imagine if CNN got hold of the story. They would plaster the headlines with: University testing illegal Russian drugs for potency.

Comment Re:So... did he have any tested? (Score 2) 82

Such tests require sophisticated testing equipment.

Those with the equipment are not going to risk getting their labs shut down for testing illegal drugs.

The book notes that The University of Alabama at Birmingham was ready to do the testing; but the necessary approval from the FDA and university administrations simply could not be obtained.

Comment Re:Clarify this sentence, please? (Score 1) 82

Big pharma has long portrayed these foreign made pharmaceuticals as dirty and dangerous.

The quandary is that if as John Horton noted that they are indeed indistinguishable from those sold by approved pharmacies; then US pharma is selling a drug at 10x the price.

It would place them in a PR nightmare they could not get out of.

Submission + - Book review: Spam Nation 1

benrothke writes: Title:Spam Nation: The Inside Story of Organized Cybercrime-from Global Epidemic to Your Front Door

Author: Brian Krebs

Pages: 256

Publisher: Sourcebooks

Rating: 10/10

Reviewer: Ben Rothke

ISBN: 978-1402295614

Summary: Excellent expose on why cybercrime pays and what you can do about it



There are really two stories within Spam Nation: The Inside Story of Organized Cybercrime-from Global Epidemic to Your Front Door. The first is how Brian Krebs uncovered the Russian cybergangs that sent trillions of spam emails for years. As interesting and compelling as that part of the story is; the second storyline is much more surprising and fascinating.



Brian Krebs is one of the premier cybersecurity journalists. From 1995 to 2009, he was a reporter for The Washington Post, where he covered Internet security, technology policy, cybercrime and privacy issues. When Krebs presented the Post with his story about the Russian spammers, rather than run with it, the Post lawyers got in the way and were terrified of being sued for libel by the Russians. Many of the stories Krebs ran took months to get approval and many were rejected. It was the extreme reticence by the Post to deal with the issue that ultimately led Krebs to leave the paper.



Before Krebs wrote this interesting book and did his groundbreaking research, it was clear that there were bad guys abroad spamming American's with countless emails for pharmaceuticals which led to a global spam problem.



Much of the story details the doings of two of the major Russian pharmacy spammer factions, Rx-Promotion and GlavMed. In uncovering the story, Krebs had the good fortune that there was significant animosity between Rx-Promotion and GlavMed, which lead to an internal employee leaking a huge amount of emails and documents. Krebs obtained this treasure trove which he used to get a deep look at every significant aspect of these spam organizations. Hackers loyal to the heads of Rx-Promotion and GlavMed leaked this information to law enforcement officials and Krebs in an attempt to sabotage each other.



Krebs writes that the databases offered an unvarnished look at the hidden but burgeoning demand for cheap prescription drugs; a demand that appears driven in large part by Americans seeking more affordable and discreetly available medications.



Like many, I had thought that much of the pharmaceutical spam it was simply an issue of clueless end-users clicking on spam and getting scammed. This is where the second storyline comes in. Krebs notes that the argument goes that if people simply stopped buying from sites advertised via the spam that floods our inboxes, the problem would for the most part go away. It's not that the spam is a technology issue; it's that the products fill an economic need and void.



Krebs shows that most people who buy from the spammers are not idiots, clueless or crazy. The majority of them are performing rational, if not potentially risky choices based on a number of legitimate motivations. Krebs lists 4 primary motivations as: price and affordability, confidentiality, convenience & recreation or dependence.



Most of the purchasers from the Russian spammers are based in the US, which has the highest prescription drug prices in the world. The price and affordability that the spammers offer is a tremendous lure to these US consumers, many of whom are uninsured or underinsured.



Krebs then addresses the obvious question that this begs: if the spammers are selling huge amounts of bogus pharmaceuticals to unsuspecting Americans, why doesn't the extremely powerful and well-to-do pharmaceutical industry do something about it. Krebs writes that the pharmaceutical industry is in fact keenly aware of the issue but scared to do anything about it. Should the reality be that the unauthorized pharmaceuticals are effective, then the pharmaceutical industry would be placed in a quandary. They have therefore decided to take a passive approach and do nothing.



The book quotes John Horton, founder and president of LegitScript, a verification and monitoring service for online pharmacies. Horton observed that only 1% of online pharmacies are legitimate. But worse than that, he believes that the single biggest reason neither the FDA nor the pharmaceutical industry has put much effort into testing, is that they are worried that such tests may show that the drugs being sold by many so-called rogue pharmacies are by and large chemically indistinguishable from those sold by approved pharmacies.



So while the Russian spammers may be annoying for many, they have found an economic incentive that is driving many people to become repeat customers.



As to the efficacy of these pharmaceuticals being shipped from India, Turkey and other countries, it would seem pretty straightforward to perform laboratory tests. Yet the university labs that could perform these tests have found their hands-tied. In order to test the pharmaceuticals, they would have to order them, which is likely an illegal act. Also, the vast amount of factories making these pharmaceuticals makes it difficult to get a consistent set of findings.



As to getting paid for the products, Krebs writes how the thing the spammers relied on most was the ability to process credit card payments. What they feared the most were chargebacks; which is when the merchant has to forcibly refund the customer. If the chargeback rate goes over a certain threshold, then the vendor is forced to pay higher fees to the credit card company or many find their merchant agreement cancelled. The spammers were therefore extremely receptive to customer complaints and would do anything to make a basic refund than a chargeback. This was yet another economic incentive that motivated the spammers.



As to the main storyline, the book does a great job of detailing how the spam operations worked and how powerful they became. The spammers became so powerful, that even with all the work firms like Blue Security Inc. did, and organizations such as Spamhaus tried to do, they were almost impossible to stop.



Krebs writes how spammers now have moved into new areas such as scareware and ransomware. The victims are told to pay the ransom by purchasing a prepaid debit card and then to send the attackers the card number to they can redeem it for cash.



The book concludes with Krebs's 3 Rules for Online Safetynamely: if you didn't go looking for it, don't install it; if you installed it, update it and if you no longer need it, remove it.



The scammers and online attackers are inherent forces in the world of e-commerce and it's foolhardy to think any technology or regulation can make them go away. Spam Nationdoes a great job of telling an important aspect of the story, and what small things you can do to make a large difference, such that you won't fall victim to these scammers. At just under 250 pages, Spam Nationis a quick read and a most important one at that.







Reviewed by Ben Rothke

Submission + - Book review: Bulletproof SSL and TLS

benrothke writes: Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications

Author: Ivan Ristic

Pages: 530

Publisher: Feisty Duck

Rating: 10/10

Reviewer: Ben Rothke

ISBN: 978-1907117046

Summary: Tremendous guide on how to correctly deploy TLS by one of the top experts in the field



If SSL is the emperor's new clothes, then Ivan Ristic in Bulletproof SSL and TLShas shown that perhaps the emperor isnt wearing anything at all. There is a perception that if a web site is SSL secured, then it's indeed secure. Read a few pages in this important book, and the SSL = securitymyth is dispelled.



For the first 8 of the 16 chapters, Ristic, one of the greatest practical SSL./TLS experts around, spends 230 pages showing countless weaknesses, vulnerabilities, attacks and other SSL weaknesses. He then spends the next 8 chapters showing how SSL can, if done correctly, be deployed to provide adequate security.



Ristic is the author of the SSL Labs web site; a site dedicated to everything SSL, including extensive documents and tools.



One would think that it's impossible to write an interesting book about a security protocol. But for those who use SSL or just want to understand what it's all about, the book is not only quite practical, but a very interesting read.



The book provides a good balance of overview, protocol details, summary of vulnerabilities and weaknesses, and a large chunk of practical deployment guidance.



The first three chapters provide an excellent overview to SSL, TLS, PKI and cryptography. While chapter 2 may be a bit dry, the introduction is thorough and comprehensive.



Chapter 4 is particularly interesting in that the author notes that while the cryptography behind SSL and PKI is fundamentally secure, there is an inherent flaw in how PKI operates, in that any CA (certificate authority) is able to issue a certificate for any name without have to seek approval from the domain name owner. This trust dependency creates numerous attack vectors that can be exploited.



The chapter details a number of significant incidents that arose from this flaw, from the 2001 code signing certificate mistake; where Verisign mistakenly issued Class 3 code signing certificates to someone claiming to be a Microsoft employee, to the Flame malware, which was signed with a bogus certificate that was seemingly signed by Microsoft, to a number of other issues.



In chapter 5, the book details a number of HTTP and browser issues, and related TLS threats. Attacks such as sidejacking, cookie stealing, cookie manipulation and more are detailed.



The author wisely notes that cookies suffer from two main problems: that they were poorly designed to being with, allowing behavior that encourages security weaknesses, and that they are not in sync with the main security mechanisms browsers use today, namely same-origin policy (SOP).



The chapter also details a significant TLS weakness in that that certificate warnings generated often leaves the clueless user to make the correct decision on how to proceed.



Ristic writes that if you receive an alert about an invalid TLS certificate, the right thing to do is immediately abandon the connection attempt. But the browser won't do that. Browser vendors decided not to enforce TLS connection security; rather they push the problem down to the user in the form of a certificate warning.



The problem is that when a user gets a certificate warning error, they simply don't know what to do to determine how big of an issue it really is, and will invariably choose to override the warning, and proceed to the website.



The challenge the user face is that these certificate warning errors are pervasive. In 2010, Ristic scanned about 119 million domain names (.com, .net and .org) searching for TLS enables sites. He found that over 22 million or 19% of the sites hosted in roughly 2 million IP addresses. But only about 720,000 had certificates whose names matches the intended hostname.



The chapter also details that the biggest problem with security indicators, similar to the certificate warnings, is that most users don't pay attention to them and possible don't even notice them.



As valuable as the first half of the book is, its significance really comes alive starting in chapter 8 on deployment issues. The level of security TLS offers only works when it is deployed correctly, and the book details how to do that. Given that OpenSSL, which is the most widely used SSL/TLS library, is notorious for being poorly documented and difficult to use, the deployment challenges are a significant endeavor.



Another issue with TLS, is that it can create performance issues and chapter 9 provides a lot of insight on performance optimization. The author quotes research from Google that SSL/TLS on their email systems account for less than 1% of the CPU load, less than 10kb of memory per connection, and less than 2% of the network overheard. The author writes that his goal is to enable the reader to get as close as possible to Google's performance numbers.



SSL/TLS has a reputation for being slow, but that is more a remnant of years ago when CPU's were much slower. With better CPU's and the optimization techniques the book shows, there is no reason not to use TLS.



For those that want an initial look, the table of contents, preface, and chapter 1 are available here. Once you get a taste of what this book has to offer, you will want to read the entire book.



As noted earlier, OpenSSL is poorly documented. InBulletproof SSL and TLS, Ivan Ristic has done the opposite: he has written the most readable and insightful book about SSL/TLS to date. TLS is not so difficult to deploy, but incredibly easy to deploy incorrectly. Anyone who is serious about ensuring that their SSL/TLS deployment is effective should certainly read this book.





Reviewed by Ben Rothke

Submission + - Book review: Countdown to Zero Day: Stuxnet and the Launch of the World's First

benrothke writes: Countdown to Zero Day: Stuxnet and the Launch of the Worlds First Digital Weapon

Author: Kim Zetter

Pages: 448

Publisher: Crown

Rating: 10/10

Reviewer: Ben Rothke

ISBN: 978-0770436179

Summary: Outstanding narrative about Stuxnet — how it was developed, quarantined and debugged





A word to describe the book Takedown: The Pursuit and Capture of Americas Most Wanted Computer Outlaw was hyperbole. While the general storyline from the 1996 book was accurate, filler was written that created the legend of Kevin Mitnick. This in turn makes the book a near work of historical fiction.



Much has changed in nearly 20 years and Countdown to Zero Day: Stuxnet and the Launch of the Worlds First Digital Weaponhas certainly upped the ante for accurate computer security journalism.



The book is a fascinating read and author Kim Zetters attention to detail and accuracy is superb. In the inside cover of the book, Kevin Mitnick describes this as an ambitious, comprehensive and engrossing book. The irony is not lost in that Mitnick was dogged by misrepresentations in Markoff's book.



For those that want to know the basics about Stuxnet, its Wikipediaentry will suffice. For a deeper look, the book take a detailed look at how the Stuxnet worm of 2010 came to be, how it was written, discovered and deciphered, and what it means for the future and provides nearly everything known to date about Stuxnet.



The need to create Stuxnet was the understanding that a nuclear Iran was dangerous to the world. The book notes that it just wasn't the US and Israel that wanted a nuclear free Iran; Egypt and Saudi Arabia were highly concerned about the dangers a nuclear Iran would bring to the region.



What is eminently clear is that Iran chronically lied about their nuclear intentions and actions (chapter 17 notes that former United Kingdom Prime Minister Gordon Brown told the international community that they had to do something over Iran's serial deception of many years) and that the United Nations International Atomic Energy Agency (IAEA) is powerless to do anything, save for monitoring and writing reports.



Just last week, President Obama said a big gap remains in international nuclear negotiations with Iran and he questioned whether talks would succeed. He further said "are we going to be able to close this final gap so that (Iran) can reenter the international community, sanctions can be slowly reduced and we have verifiable, lock tight assurances that they cant develop a nuclear weapon, theres still a big gap. We may not be able to get there". It's that backdrop to which Stuxnet was written.



While some may debate if Stuxnet was indeed the worlds first digital weapon, it's undeniable that it is the first piece of known malware that could be considered a cyber-weapon. Stuxnet was unlike any other previous malware. Rather than just hijacking targeted computers or stealing information from them, it created physical destruction on centrifuges the software controlled.



At just over 400 pages, the book is a bit wordy at times, but Zetter does a wonderful job of keeping the book extremely readable and the narrative enthralling. Writing about debugging virus code, Siemens industrial programmable logic controllers (PLC) and Step7 software (which was what Stuxnet was attacking) could easily be mind-numbingly boring, save for Zetter's ability to make it a compelling read.



While a good part of the book details the research Symantec, Kaspersky Lab and others did to debug Stuxnet, the book doesn't have and software code, which makes it readable for the non-programmer. The book is technical and Zetter gets into the elementary details of how Stuxnet operated; from reverse engineering, digital certificates and certificate authorities, cryptographic hashing and much more. The non-technical reader certainly won't be overwhelmed, but at the same time might not be able to appreciate what went into designing and making Stuxnet work.



As noted earlier, the book is extremely well researched and all significant claims are referenced. The book is heavily footnoted, which makes the book much more readable than the use of endnotes. Aside from the minor error of mistakenly calling Kurt Gödel a cryptographer on page 295, he was a logician; Zetter's painstaking attention to detail is to be commended.



Whoever wrote Stuxnet counted on the Iranians not having the skills to uncover or decipher the malicious attacks on their own. But as Zetter writes, they also didn't anticipate the crowdsourced wisdom of the hive — courtesy of the global cybersecurity community that would handle the detection and analysis for them. That detection and analysis spanned continents and numerous countries.



The book concludes with chapter 19 — Digital Pandora — which departs from the details of Stuxnet and gets into the bigger picture of what cyber-warfare means and its intended and unintended consequences. There are no simple answers here and the stakes are huge.



The chapter quotes Marcus Ranum who is outspoken on the topic of cyber-warfare. At the 2014 MISTI Infosec World Conference, Ranum gave a talk on Cyberwar: Putting Civilian Infrastructure on the Front Lines, Again. Be it the topic or Marcus just being Marcus, a third of the participants left within the first 15 minutes. But they should have stayed, as Ranum, agree with him or not, provided some riveting insights on the topic.



The book leave with two unresolved questions; who did it, and how did it get into the Nantanz enrichment facility.



It is thought the US with some assistance from Israel created Stuxnet; but Zetter also writes that Germany and Great Britain may have done the work or at least provided assistance.



It's also unknown how Stuxnet got into the air-gapped facility. It was designed to spread via an infected USB flash drive. It's thought that since they couldn't get into the facility, what needed to be done was to infect computers belonging to a few outside firms that sold devices that would in turn be connected to the facility. The book identified a few of these companies, but it's still unclear if they were the ones, or the perpetrators somehow had someone on the inside.



As to zero day in the title, what was unique about Stuxnet is that it contained 5 zero day exploits. Zero day is also relevant in that Zetter describes the black and gray markets of firms that discover zero-day vulnerabilities who in turn sell them to law enforcement and intelligence agencies.



Creating Stuxnet was a huge challenge that took scores of programmers from a nation state many months to create. Writing a highly readable and engrossing book about the obscure software vulnerabilities that it exploited was also a challenge, albeit one that few authors could do efficaciously. InCountdown to Zero Day: Stuxnet and the Launch of the Worlds First Digital Weapon, Kim Zetter has written one of the best computer security narratives; a book you will likely find quite hard to put down.





Reviewed by Ben Rothke

Comment Re:Media Coverage of Risk (Score 1) 46

Bruce Schneier has a good essay on this topic - Virginia Tech Lesson: Rare Risks Breed Irrational Responses - https://www.schneier.com/essay...

He sums it up with novelty + dread = overreaction.

Ebola fits that. From a public heath perspective for the US, Ebola is for the most part a non-issue.

Slashdot Top Deals

There are two ways to write error-free programs; only the third one works.

Working...