text:
Friday, July 27, 2007
Goodbye AIA
I realized that last month what used to be Air Intelligence Agency is now Air Force Intelligence, Surveillance and Reconnaissance Agency, according to this story. AFISR now works as a field operating agency for AF/A2, the Deputy Chief of Staff for Intelligence, Surveillance and Reconnaissance, Lt. Gen. David A. Deptula. AIA was part of 8th Air Force, but that experiment has been reversed.
It looks like AFISR has lost information operations duties since it's now an "ISR" agency. According to Air Force ISR Agency, the AF/A2 says:
"Air Intelligence Agency was traditionally focused on a particular intelligence discipline, signals intelligence," said General Koziol. "Now we are expanding our capabilities into geo-spatial-intelligence, imagery, human intelligence, and measurement and signature intelligence disciplines. As an integral member of our nation's combat forces, we are focused on integrating the information derived by those capabilities and delivering critical information to combatant commanders and national level decision makers."
That's news to me. I think AIA was doing those missions previously, but Deptula wants a single agency responsible for all of it. He gets that with AFISR. Information operations are now part of Air Force Cyber Command, which apparently will become active this fall.
I have mixed feelings about AIA's fate. Lt. Gen. Deptula is a three-star, which outranks previous top intel generals (who were two-stars). Putting a three-star with ISR responsibilities at HQ AF will probably give ISR greater attention. However, the word "intel" appears three times in Deptula's bio -- all in relation to his existing job. He's a career F-15 driver, so once again we have a pilot as the Air Force's "top intel guy." This is sad. Are there no good Air Force intel generals available? Hopefully the new AFISR commander, Maj. Gen. John C. Koziol, will be able to step up when Deptula moves on.
The only saving grace in this situation is that the king of all intel officers continues to be Gen. Michael Hayden, Director of the Central Intelligence Agency.
Thursday, July 26, 2007
Bejtlich Interviewed by TSSCI Blog
Tuesday, July 24, 2007
Enterprise Visibility Architect
Right now you're [developers] being taught (hopefully) "secure coding." I would like to see the next innovation be security application instrumentation, where you devise your application to report not only performance and fault logging, but also security and compliance logging.
This is a forward-looking plea. In the meantime, we are stuck with numerous platforms, operating systems, applications, and data (POAD) for which we have zero visibility.
I suggest that enterprises consider hiring or assigning a new role -- Enterprise Visibility Architect. The role of the EVA is to identify visibility deficiencies in existing and future POAD and design solutions to instrument these resources.
What does this mean in real life? Here is an example. Let's say a company operates a FTP proxy for business use. Consider various stakeholders involved with that server and the sorts of visibility they might want:
- Data center managers want physical accountability for the server. They also want to know how much power is consumed and how much heat is output.
- Network administrators want to know how much bandwidth the server uses for OS and application updates. They also want to know how much bandwidth is used by data transfers and backup processes.
- System administraors want to know if the asset is performing properly.
- Users and asset owners want to know how much data is transferred (in the vent they are billed for this service).
- Human resources administrators and legal want to know what files are transferred, potentially to identify fraud, waste, and abuse.
- Auditors want to validate and asses secure configurations.
- Security analysts want to resist, detect, and respond to incidents.
- Forensic investigators want to know the state of the asset and the files transferred to investigate incidents.
These are all requirements that should be included in the design of the server before it is deployed. However, no one does all of this, and only a few organizations accomplish a few of these items. The role of the EVA is to ensure all of these requirements are built into the design.
When these requirements are not built into the design (as is the case with 95+% of all infrastructure, I would wager) it's the job of the EVA to work with concerned parties to introduce visibility through instrumentation. For example, how could the investigators' concern be met?
- If the proxy supports logging, enable it. (This is usually not done because of "performance concerns." If the resource were appropriately sized prior to deployment to account for visibility, this would not be a problem.)
- Add a passive device to monitor traffic to and from the proxy server. Application-aware monitoring tools like Bro's FTP Analyzer can record FTP control channel activities. (The resistance to this technique involves not wanting to configure a SPAN port, or lack of a SPAN port. I prefer taps, but inserting the tap requires scheduling downtime -- another sticking point.)
- If the investigator only wants IP addresses for the endpoints, then NetFlow could be enabled on a router through which traffic to the FTP server passes. Note that NetFlow cannot be configured to only provide flow data for a specific port (like 21 TCP) so filtering would have to happen on the NetFlow collector. Using NetFlow effectively requires building a NetFlow collector. (Other concerns include loading the router, which could have been accounted for when the design for this business system was created.)
- If the investigator only wants IP addresses for the endpoints, then a logging ACL could be enabled on a router through which traffic to the FTP server passes. Hits on this ACL could be exported via Syslog. Using Syslog requires building a Syslog server. (This option will also add load to the router.)
- Depending on the architecture, intervening firewalls could also be configured to log connection details in the same manner that NetFlow or router ACLs do.
I believe that logging integrated into the application (i.e., the FTP process) is the best option when one is designing a new resource. When visibility is introduced after the asset is deployed, instrumenting it becomes more difficult.
If you hadn't guessed, I am becoming the de facto EVA in my job as director of incident response because I need data to detect and respond to incidents. However, all of the stakeholders are natural allies because they want to know more about various assets.
Thanks to the I want to believe generator for the image above.
Recent CVS Changes
Earlier this year I posted TaoSecurity CVS at Sourceforge and Committing Changes to CVS. Since posting my Sguil on FreeBSD scripts at TaoSecurity Sourceforge I needed to make a few changes. The system hosting my original files suffered a lightning strike, so I decided to retrieve the files from CVS and make changes.
Checking out the scripts can be done anonymously without a password. (Note there are some artificial line breaks in these and other lines.)
$ cvs -d:pserver:email@example.com:/cvsroot/taosecurity
Logging in to :pserver:email@example.com:2401
CVS password:
$ cvs -d:pserver:email@example.com:/cvsroot/taosecurity
co -P taosecurity_sguil_scripts
cvs checkout: Updating taosecurity_sguil_scripts
U taosecurity_sguil_scripts/README
When I checked out these files they had headers like this:
# $Id: README,v 1.2 2007/03/22 18:40:25 taosecurity Exp $ #
These headers are added by lines like this from the original files:
# $Id$ #
In order to turn these new checked out files into files that would have the proper headers, I replaced these specific lines in each file with the tag # $Id$ #.
I added several files to the scripts, but for purposes of documentation I'll show how I added one -- sguild_start.sh. I had to connect via SSH to do this.
$ export CVS_RSH=ssh
$ cvs -d:ext:firstname.lastname@example.com:/cvsroot/taosecurity
add sguild_start.sh
firstname.lastname@example.com's password:
cvs add: scheduling file `sguild_start.sh' for addition
cvs add: use 'cvs commit' to add this file permanently
$ cvs -d:ext:firstname.lastname@example.com:/cvsroot/taosecurity
commit sguild_start.sh
email@example.com's password:
RCS file: /cvsroot/taosecurity/taosecurity_sguil_scripts/sguild_start.sh,v
Checking in sguild_start.sh;
/cvsroot/taosecurity/taosecurity_sguil_scripts/sguild_start.sh,v <-- sguild_start.sh
initial revision: 1.1
I think I could have set a CVSROOT variable instead of specifying everything on the command line, perhaps like:
$ export CVSROOT=:ext:email@example.com:/cvsroot/taosecurity
Setting that I could ignore the entire -d switch.
When I add or commit files I could add a -m "Comment" line to describe the change.
Currently my scripts assume installation using FreeBSD 6.2, using the packages in the packages-6.2-release directory. The only exception is the package for tcltls because it was not shipped with 6.2.
Saturday, July 21, 2007
Review of XSS Attacks Posted
XSS Attacks earns 4 stars for being the first book devoted to Cross Site Scripting and for rounding up multiple experts on the topic. The authors are synonymous with attacking Web applications and regularly share their vast expertise via their blogs and tools. However, XSS Attacks suffers the same problems found whenever Syngress rushes a book to print -- nonexistent editing and uneven content. I found XSS Attacks to be highly enlightening, but I expect a few other books on the topic arriving later this year could be better.
Thanks to Syngress I have review copies of Snort Intrusion Detection and Prevention Toolkit and Stealing the Network: How to Own a Shadow, which I plan to read soon. More late nights in my future...
Friday, July 20, 2007
Glutton for ROI Punishment
It's 1992. Happy Corp. is a collaborative advertisement writing company. A team of writers develop advertisement scripts for TV. Writers exchange ideas and such via hard copy before finalizing their product. Using these methods the company creates an average of 100 advertisement scripts per month, selling them for $1,000 each or a total of $100,000 per month.
Happy's IT group proposes Project A. Project A will cost $10,000 to deploy and $1,000 per month to sustain. Project A will provide Happy with email accounts for all writers. As a result of implementing Project A, Happy now creates an average of 120 scripts per month. The extra income from these scripts results in recouping the deployment cost of Project A rapidly, and the additional 20 scripts per month is almost all profit (minus the new $1,000 per month charge for email).
Now it's 1993, and Happy Corp. faces a menace -- spam. Reviewing and deleting spam emails lowers Happy's productivity by wasting writer time. Instead of creating 120 scripts per month, Happy's writers can only produce 110 scripts per month.
Happy's security group proposes Project B. Project B will cost $10,000 to deploy and $1,000 per month to sustain. (Project B does not replace Project A.) Project B will filter Happy's email to eliminate spam. As a result of implementing Project B, Happy returns to creating an average of 120 scripts per month. Profits have increased but they do not return to the level enjoyed by the pre-spam days, due to the sustainment cost of Project B.
I would say Project A provides a true return on investment. I would say Project B avoids loss, specifically the productivity lost by wasting time deleting spam.
I could see how others could make an argument that Project B is a productivity booster, since it does return productivity to the levels seen in the pre-spam days. That is the common ground I hope to achieve with this explanation. I do not consider that a true productivity gain because the productivity is created by the email system Project A, but I can accept others see this differently.
I think this example addresses the single biggest problem I have seen in so-called "security ROI" proposals: the failure to tie the proposed security project to a revenue-generating business venture. In short, security for "security's sake" cannot be justified.
In my scenario I am specifically stating that the company is losing revenue of 10 scripts per month because of security concerns, i.e., spam. By spending money on spam filtering, that loss can be avoided. Assuming the overall cost of Project B is less than or equivalent to the revenue of those lost 10 scripts per month, implementing Project B makes financial sense.
What do you think?
Thursday, July 19, 2007
Managing and Monetizing Victims
My point is the vast majority of enterprises have not known about this, and they have no way to know if they've been affected. However, if you've been implementing Network Security Monitoring for any decent period of time, you have a rich data source to mine for indications of this activity. Now that you know what to look for, you can see if you're affected. The power of NSM is keeping track of what's happening on your network so that you can perform investigations once you know where to look.
A news story on fast flux is Attackers Hide in Fast Flux.
Second, Prevx posted a blog entry titled Ransomware... Holding Corporate America Ransom! that outlines another extortion attempt whereby an intruder will encrypt a victim's data if $300 isn't paid. The fact that money is explicitly involved means law enforcement should be able to "follow the money" to find the attacker, but still consider this: what would your organization do if executives and/or users received such notifications? Worse, what if your data was simply deleted, encrypted, or subtly altered, nevermind outright stolen? In other words, you aren't extorted -- you're simply assaulted.
While ransomware is not a new phenomenon, many people do not stop to think of the damage that can be done by not maintaining control of one's assets. Some of you will say "oh, we'll restore from backups." What do you do if you have dozens, hundreds, thousands of users affected? My point is we have to treat compromise of the endpoint as a serious matter, not something that has little or no consequence.
A news story on ransomware is Your Money or Your Documents.
On a related note, check out New Proxy Bot Method and Sigs. Basically the Bleeding Threats team has detected malware that uses compromised hosts as a proxy back into the corporate network. David Bianco reminded me that the Metasploit Meterpreter's portfw function provides the same capability. In other words, once a host is compromised via a client-side attack and it reports back to its command server, the command server can use the new victim as a stepping stone to attack any other reachable part of the enterprise.
Knowing how all three of these attacks operates allows us to build attack profiles so we can better resist, detect, and respond to them when they occur.
Update: Check out Passive Monitoring of DNS Anomalies at CAIDA.
Wednesday, July 18, 2007
NoVA Sec and NoVA BUG
Review Posted Plus NAC
Unfortunately, as you'll read in my three star review, you can skip Endpoint Security:
I really looked forward to reading Endpoint Security. I am involved in a NAC deployment, and I hoped this book could help. While the text does contain several statements that make sense (despite being blunt and confrontational), the underlying premise will not work. Furthermore, simply identifying and understanding the book's central argument is an exercise in frustration. Although Endpoint Security tends not to suffer any technical flaws, from conceptual and implementation points of view this book is disappointing.
I just finished this review, and it took a long time to write. Please read the review before commenting. I would like to mention one element of my review here, which contains a quote from Microsoft's article Planning for Network Access Quarantine Control:
On p 172 Microsoft says "Network Access Quarantine Control is not a security solution. It is designed to help prevent computers with unsafe configurations from connecting to a private network, not to protect a private network form malicious users who have obtained a valid set of credentials."
I've written about NAC several times for this blog, such as NAC Is Fighting the Last War. However, I find this Microsoft comment to be fairly realistic. Prior to that statement, quoted in Endpoint Security, Microsoft says this:
Because typical remote access connections only validate the credentials of a remote access user, a remote access client that connects to a private network can access network resources even if the configuration of the remote access client does not comply with corporate network policies. You can implement Network Access Quarantine Control to delay normal remote access to a private network until the configuration of the remote access client has been examined and validated by a client-side script.
The emphasis here is on configuration, i.e., compliance with policy, and not integrity of the endpoint. Compliance with policy != integrity or security (i.e., the state of not being compromised). NAC is incapable of validating the integrity of an endpoint. (There's the controversy for this post. Cue responses from NAC vendors.)
My point is that's ok, as long as your expectations are aligned with Microsoft's description of their capabilities. Now, it is possible for a compromised system to report that its configuration meets corporate policies while being under the control of a Romanian. I don't see the logic in trusting the endpoint to report its health, especially via a "client-side script." However, if your primary reason for deploying NAC is to get a better grip on configuration enforcement for endpoints, I think it has some merit -- it depends on the cost of the implementation and your goals for the process.
By the way, Wikipedia's entries for PID controller will help make sense of Endpoint Security's discussion of CLCP.
No Undetectable Breaches
...what if the enemy has a stealth plane that we cannot detect via radar, satellite, wind-speed variance, or any other deployed means? And what if your intel doesn't tell us that such a vehicle exists? Then we have potentially millions of airspace breaches every year and our outcome metrics are not helping.
I'm not disagreeing with you that outcome metrics are ideally better data than compliance metrics. However, outcome metrics are difficult to identify and collect data on, and it can be difficult to discern how accurate your metrics actually are.
At least with compliance metrics, we can determine how good we are at doing what it is we say that we do. It has little relevance to operational security, but it's easy and the auditors seem to like it.
For the case of a single breach, or even several breaches, it may be possible for them to happen and be completely undetectable. However, I categorically reject the notion that it is possible to suffer sustained, completely undetectable breaches and remain unaware of the damage. If you are not suffering any damage due to these breaches, then why are you even trying to deter, detect, and respond to them in the first place?
Let me put this in perspective by considering labels attached to classified information as designated by Executive Order 12356:
(a) National security information (hereinafter "classified information") shall be classified at one of the following three levels:
- "Top Secret" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause exceptionally grave damage to the national security.
- "Secret" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause serious damage to the national security.
- "Confidential" shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause damage to the national security.
We want to protect the confidentiality of classified information to avoid the losses described above. What happens if we suffered sustained breaches (thefts) of Top Secret data? Are we not going to detect that our national security concerns are being hammered, since we are suffering "exceptionally grave damage"?
This is one way spies are unearthed. If your missions are constantly failing because the enemy seems to know your plans, then your suffering a breach you haven't detected it.
Finally, if you are suffering breaches and your input-based metrics aren't detecting them either, what good are they? Talk about a real waste of money. "It's easy and auditors seem to like it?" Good grief.
Tuesday, July 17, 2007
NORAD-Inspired Security Metrics
Today I remembered NORAD and considered their mission with respect to my post last year titled Control-Compliant vs Field-Assessed Security. In case you can't tell from the pithy title, the central idea was that it's more effective to measure security by assessing outcomes instead of inputs. For example, who cares if 100% of your systems have Windows XP SP2 if they are all 0wned by a custom exploit written just for your company? Your security has failed. Inputs are important, but my experience with various organizations is that they tend to be the primary means of "measuring" security, regardless of how well they actually preserve the CIA triad.
Let's put this in terms of NORAD, whose front page states:
The North American Aerospace Defense Command (NORAD) is a bi-national United States and Canadian organization charged with the missions of aerospace warning and aerospace control for North America. Aerospace warning includes the monitoring of man-made objects in space, and the detection, validation, and warning of attack against North America whether by aircraft, missiles, or space vehicles, through mutual support arrangements with other commands. Aerospace control includes ensuring air sovereignty and air defense of the airspace of Canada and the United States...
To accomplish the aerospace warning mission, the commander of NORAD provides an integrated tactical warning and attack assessment to the governments of Canada and the United States. To accomplish the aerospace control mission, NORAD uses a network of satellites, ground-based radar, airborne radar and fighters to detect, intercept and, if necessary, engage any air-breathing threat to North America.
What are some control-compliant or input metrics for NORAD?
- Number of planes at the ready for intercepting rogue aircraft
- Average pilot rating (i.e., some sort of assessment of pilot skill)
- Radar uptime
- Radar coverage (e.g., percentage of North American territory monitored)
These are all interesting metrics. You might see some comparisons to metrics you might track, like percentage of hosts with anti-virus.
Now consider: do any of those metrics tell you if NORAD is accomplishing its mission? In other words, what is the outcome of all those inputs? What is the score of this game?
Here are some field-assessed or outcome-based metrics.
- Number of rogue aircraft penetrating North American territory (indicates a failure to deter activity)
- Number of aircraft not detected by NORAD but discovered via other means to have penetrated North American territory (perhaps via intel sources; indicates a failure to detect activity)
- Number of aircraft not repelled by interceptors (hopefully this would never happen!)
- Time from first indication of rogue aircraft to launching interceptors (indicates effectives of pilot-to-plane-to-air process)
These metrics address the critical concern: accomplishing the mission.
Keep these in mind when you are devising metrics for your digital security program.
Another Review, Another Pre-Review
Network Warrior is the best network administration book I've ever read.
I spend most of my reading time on security books, but because I lean towards network security I like reading complementary sources on protocols and infrastructure.
Gary Donahue has written a wonderful book that I highly recommend for anyone who administers, supports, or interacts with networks. Network Warrior may be the best book I will read in 2007.
Yeah, I liked it that much. I devoured this book, staying up until 1 am or more several nights in a row.
I'm looking forward to reading Mark Kadrich's Endpoint Security. I think this book will directly affect how I approach some projects at work. I really hope it can help me better understand how to deal with endpoint security in 2007. It's taken me a while to get this book. For some reason it was published in "March 2007" but only available recently.
I'd like to briefly mention a new book that's great, but which I won't read and review: Exploiting Online Games: Cheating Massively Distributed Systems by Greg Hoglund and Gary McGraw. I reviewed drafts of this book and I think the underlying message behind the code is extremely important. To understand why, please read this post by Brian Chess. He makes a much better case than I could. Because I am so time-crunched, and I really do not care about the details of exploiting WoW, I am not going to review Exploiting Online Games. I will have a couple copies to share at Black Hat for students or teaching assistants who make my life easier in class!
Sunday, July 15, 2007
Security ROI Revisited
Just read your ROI blog, which I found very interesting. ROI is something I've always tried to put my finger on, and you present an interesting approach. Question: Is it not possible to 'make' money with security, or does it still come down to savings? Example:
- A hospital implements a security system that allows doctors to access patient data from anywhere. Now, instead of doing 10 patients a day they can do (and charge) 13 patients a day.
I'm not trying to sharp shoot you in anyway, I'm just trying to better understand the economics.
This is an excellent question. This is exactly the same concept as I stated in my August 2006 post Real Technology ROI. In this case, doctors are more productive at accessing patient data by virtue of a remote access technology. This is like installing radios for faster dispatch in taxis. In both cases security is not causing a productivity gain but security can be reasonably expected as a property of a properly designed technology. In other words, it's the remote access technology that provides a productivity gain, and doctors should expect that remote access to be "secure." In a taxi, the radio technology provides a productivity gain, and drivers should expect that system to be "secure."
I'm sure that's not enough to convince some of you out there. My point is you must identify the activity that increases productivity -- and security will not be it. Don't believe me? Imagine the remote access technology is a marvel of security. It has strong encryption, authorization, authentication, accountability, endpoint control, whatever you could possibly imagine to preserve the CIA triad. Now consider what happens if, for some reason, doctors are less productive using this system. How could that happen? The system is secure! Maybe the doctors all decide to spend tons more time looking at patient records so their "throughput" declines. Who knows -- the point is that security had nothing to do with this result; it's the business activity that increases (or in this example, decreases) that determines ROI.
What does this mean for security projects? They still don't have ROI. However, and this is a source of trouble and opportunities, security projects can be components of productivity enhancing projects that do increase ROI. This is why the Chief Technology Officer (CTO) can actually devise ROI for his/her projects. As a security person, you would probably have more success in budget meetings if you can tie your initiatives to ROI-producing CTO projects.
Wait a minute, some of you are saying. How about this example: if a consumer can choose between two products (one that is "secure" and one that is not), won't choosing the "secure" model mean that security has a ROI, because the company selling the secure version might beat the competition? In this case, remember that the consumer is not buying security; the consumer is buying whatever a product that performs some desired function, and security is an "enabler" (to use a popular term). If the two products are functionally equivalent and the same price, buying the "secure" version is a no-brainer because, even if the risk is exceptionally small, "protecting" against that risk is cost free. If the "secure" version is more expensive, now the consumer has to remember his/her CISSP stuff, like Annualized Rate of Occurrence (ARO) and Single Loss Expectancy (SLE) to devise an Annual Loss Expectancy (ALE), where
You then compare your ALE to the cost differential and decide if it's worth paying the extra amount for the "secure" product.
For those of you who still resist me, it's as simple as this: security is almost always concerned with stopping bad events. When you stop a bad event, you avoid a loss. Loss avoidance means savings, but no business can stay in business purely by saving money. If you don't understand that you will never be able to understand anything else about this subject. You should also not run a business.
The reason why you should pursue projects that save money is that those projects free resources to be diverted to projects with real ROI. Those of you who have studied some economics may see I am getting close to Frédéric Bastiat's Broken Window fallacy, briefly described by Russell Roberts thus:
Bastiat used the example of the a broken window. Repairing the window stimulates the glazier's pocketbook. But unseen is the loss of whatever would have been done with the money instead of replacing the window. Perhaps the one who lost the window would have bought a pair of shoes. Or invested it in a new business. Or merely enjoyed the peace of mind that comes from having cash on hand.
Spending money on security breaches is repairing a broken window. Spending money to prevent security breaches is like hiring a guard to try to prevent a broken window. In either case, it would have been more productive to be able to invest either amount of money, and a wise investment would have had a positive ROI. This is why we do not spend time breaking and repairing windows for a living in rich economies.
However, like all my posts on this subject, I am not trying to argue against security. I am a security person, obviously. Rather, I am arguing against those who warp security to fit their own agenda or the distorted worldview of their management.
For an alternative way to talk to management about security, I recommend returning to my post Risk-Based Security is the Emperor's New Clothes where I cite Donn Parker.
Saturday, July 14, 2007
No ROI? No Problem
In its simplest form, ROI is a mechanism used to choose projects. For example, assume you have $1000 in assets to allocate to one of three projects, all of which have the same time period and risk.
- Invest $1000. Project yields $900 (-10% ROI)
- Invest $1000. Project yields $1000 (0% ROI)
- Invest $1000. Project yields $1100 (10% ROI)
Clearly, the business should pursue project 3.
Businesspeople make decisions using this sort of mindset. I am no stranger to this world. Consider this example from my consulting past, where I have to choose which engagement to accept for the next week.
- Spend $1000 on travel, meals, and other expenses. Project pays $900 (-10% ROI)
- Spend $1000 on travel, meals, and other expenses. Project pays $1000 (0% ROI)
- Spend $1000 on travel, meals, and other expenses. Project pays $1100 (10% ROI)
Obviously this is the same example as before, but using a real-world scenario.
The problem the "return on security investment" (ROSI) crowd has is they equate savings with return. The key principle to understand is that wealth preservation (saving) is not the same as wealth creation (return).
Assume I am required to obtain a license to perform consulting. If I buy the license before 1 January it costs $500. If I don't meet that deadline the license costs $1000. Therefore, if I buy the license before 1 January, I have avoided a $500 loss. I have not earned $500 as a result of this "project." I am not $500 richer. I essentially bought the license "on sale" compared to the post-1 January price.
Does this mean buying the license before 1 January is a dumb idea because I am not any richer? Of course not! It's a smart idea to avoid losses when the cost of avoiding that loss is equal to or less than the value of the asset being protected.
For example, what if I had to pay $600 to get a plane ticket from a far-away location to appear in person in my county to buy the license before 1 January? In that case, I should just pay the $1000 license fee later. For a $500 plane ticket, the outcome doesn't matter either way. For a $400 plane ticket, I should fly and appear in person. Again, in none of these situations am I actually richer. No wealth is being created, only preserved. There is no ROI, only potential savings.
What if I chose to avoid paying for a license altogether, hoping no one catches me? I've saved even more money -- $500 compared to the pre-1 January price, and $1000 compared to the post-1 January price. This is where the situation becomes more interesting, and this is where subjectivity usually enters the picture concerning expected outcomes.
Let's get back to ROI. The major problem the ROSI crowd has is they are trying to speak the language of their managers who select projects based on ROI. There is no problem with selecting projects based on ROI, if the project is a wealth creation project and not a wealth preservation project.
Security managers should be unafraid to avoid using the term ROI, and instead say "My project will cost $1,000 but save the company $10,000." Saving money / wealth preservation / loss avoidance is good.
Another problem most security managers will encounter is their inability to definitively say that their project will indeed save a certain amount of money. This is not the case for licensing deals, e.g., "Switching from Vendor X's SSL VPN to Vendor Y's SSL VPN will save $10,000" because the outcome is certain, breach of contract nonwithstanding. Certainty or even approximate probability is a huge hurdle for many security projects because of several factors:
- Asset value is often undetermined; in some cases, assets themselves are not even inventoried
- Vulnerabilities in assets are unknown, because new flaws are discovered every day
- The threat cannot be properly assessed, because they are unpredictable and creative
As a result, risk assessment is largely guesswork. Guesswork means the savings can be just about anything the security manager chooses to report.
If you look at my older posts on return on security investment you'll see some more advice on how to make your case for security spending without using the term "ROI".
It should be clear by now that ROSI or security ROI is nothing more than warping a defined business term to get attention during budget meetings. I saw the exact same problem in the Air Force. At one point those who flew combat missions were called "operators." Once Information Operations came into vogue, that community wanted to be called "operators" too. At one point a directive came down that intel folks like me were now "operators," just like combat pilots. That lasted about 10 minutes, because suddenly the combat pilots started using the term "trigger-pullers." "Fine," they thought. "Call yourselves operators. We pull triggers." Back to square one.
The bottom line is that security saves money; it does not create money.
Bank Robber Demonstrates Threat Models
Several aspects of the story struck me. First, this criminal struck 16 times in less than five years, only once being repelled when he was detected en route to a bank and locked out by vigilant tellers. Does a criminal who continues to strike without being identified and apprehended bear resemblance to cyber criminals? Second, the banks did not respond by posting guards on site. Guards tend to aggravate the problem and people get hurt, according to the experts cited on the show. Instead, the banks posted greeters right at the front door to say hello to everyone entering the bank. I've noticed this at my own local branch within the last year, but thought it was an attempt to duplicate Wal-Mart; apparently not. Because the robber also disguises himself with a balaclava (pictured at right), the bank banned customers from wearing hoods, sunglasses, and other clothing that obscures the face in the bank.
Third, improved monitoring is helping police profile the criminal. Old bank cameras used tape that was continuously overwritten, resulting in very grainy imagery. Newer monitoring systems are digital and pick up many details of the crime. For example, looking at recent footage the cops noticed the robber "indexing" the gun by keeping his index finger away from the trigger, like we learned in the military or in law enforcement. They also perceived indications he wears light body armor while robbing banks. Finally, one of the more interesting aspects of the show was the reference to a DoJ Bank Robbery (.pdf) document. It contains a chart titled Distinguishing Professional and Amateur Bank Robbers, reproduced as a linked thumbnail at left.
I understand the purpose of the document; it's a way to determine if the robber is an amateur or a professional. This made me consider some recent posts like Threat Model vs Attack Model. A threat model describes the capabilities and intentions of either a professional bank robber or an amateur bank robber. An attack model describes how a robber specifically steals money from a particular bank. Threat models are more generic than attack models, because attack models depend on the nature of the victim.
Watching this show reminded me that security is not a new problem. Who has been doing security the longest? The answer is: physical security operators. If we digital security newbies don't want to keep reinventing the wheel, it might make sense to learn more from the physical side of the house. I think convergence of some kind is coming, at least at some level of the management hierarchy.
If you argue that the two disciplines are too different to be jointly managed, consider the US military. The key warfighting elements are the Unified Combatant Commands, which can be headed by just about any service member. Some commands were usually led by a general from a certain service, like the Air Force for TRANSCOM, but those arrangements are being unravelled. Despite the huge Army occupation in the Middle East, for example, the next CENTCOM leader is a Naval officer, and so is the next Chairman of the Joint Chiefs. Even the new head of SOCOM is Navy. This amazes me. When I first learned about Joint warfare, the joke was "How do you spell Joint? A-R-M-Y." Now it's N-A-V-Y.
For more on this phenomenon, please read Army Brass Losing Influence, which I just found after writing this post.
Perhaps we should look to a joint security structure to combine the physical and digital worlds? That would require joint conferences and similar training opportunities. Some history books with lessons for each side would be helpful too.
Friday, July 13, 2007
Thanks for the Memories Sys Admin Magazine
- Maintaining Patch Levels with Open Source BSDs by Michael Lucas
- Landmining the Cracker's Playing Field by Amy Rich
- Hardening a Host by Dave D. Zwieback
- Intrusion Detection Strategies and Design Considerations by Ronald McCarty
- Practical Packet Sniffing by John Mechalas
No wonder I bought that issue! Michael Lucas, if you're reading this -- I marked the heck out of your article. It's one of the first artifacts I have of my involvement with FreeBSD.
After subscribing to the magazine for several years, I managed to get my first article into the April 2004 issue -- Integrating the Network Security Monitoring Model. This introduced NSM to a wide audience prior to the publication of my first book. That was followed in February 2005 with More Tools for Network Security Monitoring. I covered Dhcpdump, PADS, and SANCP. Funny, I'd forgotten all about Dhcpdump, but I might be able to use it for a certain problem. This demonstrates one of the main reasons I write -- I can't remember everything that might be helpful! In February 2006 I was confident enough to try writing about FreeBSD, so I contributed Keeping FreeBSD Up-to-Date. This detailed a variety of means to keep the FreeBSD OS up-to-date, including all the old methods plus new ones some people haven't heard about or are unwilling to try. It's nice to see many of these new methods integrated into the base OS in later versions of FreeBSD 6.x. My last article appeared in the August 2006 issue, called Tuning Snort. I talked about the essential tasks one should perform for any Snort installation.
I hope Sys Admin publishes a final CD with all of the magazine's issues. Sys Admin, thanks for the memories, for the learning, and for the opportunity to contribute.
Ivan Voras FreeBSD 7 Live CD
I think this is great. Booting the installer as a live CD lets a user see if FreeBSD recognizes hardware before committing to an installation. The user also gets to play with FreeBSD without making any changes to the production system. I downloaded the .iso and booted it in VMware to take the screen capture at left. Right now the system doesn't do much, and the keyboard mapping isn't English. (For example, obtaining the - key required me to hit the / key.) I am excited to see this and it would be great to have it ready for FreeBSD 7. I do not think it will happen, but we'll see.
Incidentally, this other SOC project looks neat: Super Tunnel Daemon:
IP can easily be tunneled over a plethora of network protocols at various layers, such as IP, ICMP, UDP, TCP, DNS, HTTP, SSH to name a few. While a direct connection may not always be possible due to a firewall, the IP packets could be encapsulated as payload in other protocols, which would get through. However, each such encapsulation requires the setup of a different program and the user has to manually probe different encapsulations to find out which of them works in a given environment.
The aim of this project is to implement the Super Tunnel Daemon, a tunneling daemon using plugins for different encapsulations and automagically selecting the best encapsulation in each environment.
That sounds like a nice capability for malicious users.
Disk Usage Pages Added to NSM Wiki
I created three more pages:
On each page I provided a sample methodology to collect disk usage information for each data type, and provided two examples of production sensors on small links collecting 14 days of data.
Please consider following the examples by adding your own numbers to each page. This will help guide partitioning and storage requirements for those trying to build and maintain NSM sensors. Thank you.
Wednesday, July 11, 2007
Snort Report 7 Posted
In the last Snort Report we looked at output methods for Snort. These included several ways to write data directly to disk, along with techniques for sending alerts via Syslog and even performing direct database inserts. I recommended not configuring Snort to log directly to a database because Snort is prone to drop packets while performing database inserts. In this edition of the Snort Report I demonstrate how to use unified output, the preferred method for high performance Snort operation.
In the next edition I plan to discuss testing Snort.
Are the Questions Sound?
Dan Geer, second of the three wise men, was kind enough to share slides from his Measuring Security USENIX class. If I were not teaching at USENIX I would be in Dan's class.
One of the slides bothered me -- not for what Dan said, but for what was said to him. The slide is reproduced above, and the notes below:
These are precisely the questions that any CFO would want to know and we are not in a good position to answer. The present author was confronted with this list, exactly as it is, by the CISO of a major Wall Street bank with the preface "Are you security people so stupid that you cannot tell me...."
This particular CISO came from management audit and therefore was also saying that were he in any other part of the bank, bond portfolios, dervative pricing, equity trading strategies, etc., he would be able to answer such questions to five digit accuracy. The questions are sound.
I think Dan is giving the CISO too much credit. I think the questions are "semi-sound," and I think the CISO is the stupid one for using such a negative word to describe one of my Three Wise Men.
I'd like to mention several factors which make comparing the world of finance different from the world of digital security. I am recording these because they are more likely the kernel for future developed ideas, but I think they are legitimate points.
- Business: Digital security is not a line of business. No one practices security to make money. Security is not a productive endeavor; security risk is essentially a tax instantiated by the evil capabilities and intentions of threats. Because security is not a line of business, the performance incentives are not the same as a line of business. Security has no ROI; proper business initiatives do. Only security vendors make money from security.
- Accumulation: Digital security, as defined by preserving the confidentiality, integrity, and availability of information, cannot be accumulated. One cannot tap a reserve of security and later replenish it. Data that is exposed to the public Internet can seldom be quashed; data that has been corrupted at time of critical use cannot be changed later, thereby changing the past; and data that was not available at a critical time cannot be made available later, thereby changing the past.
This is not the same with capital (i.e., money). Financial institutions are regulated and operated according to capitalization standards that dictate certain amounts of money to cover potential adverse events. Therefore, money can be stored as a counter to riskier behavior or decreased when pursuing less risky activities. Money at a single point in time is also homogenous; the first dollar of $100 is equally valuable as the hundreth dollar of $100. Information resources are not homogenous.
- Assumptions: Assumptions make financial "five digit accuracy" possible. Consider the assumptions made by the Black-Scholes model, courtesy of Wikipedia, used to price options:
- The price of the underlying instrument St follows a geometric Brownian motion with constant drift μ and volatility σ:
- It is possible to short sell the underlying stock.
- There are no arbitrage opportunities.
- Trading in the stock is continuous.
- There are no transaction costs or taxes.
- All securities are perfectly divisible (e.g. it is possible to buy 1/100th of a share).
- It is possible to borrow and lend cash at a constant risk-free interest rate.
- The stock does not pay a dividend (see below for extensions to handle dividend payments).
The specifics of this equation are not important for this discussion, although those of you who also studied some economics may find plenty of ways to criticize it. (Remember the authors won the Nobel Prize for this equation and paper!) Consider what you could define if digital security practitioners were able to make such assumptions.
- Accuracy: I just said "assumptions make five digit accuracy possible." This isn't really true. If financial five digit accuracy were possible, no markets could be sustained. Simply put, markets exist because two sides agree to a trade. One side sees the world in one way, and the other sees it differently. (This is why market-makers exist on trading floors. When too many traders see the world the same, market-makers provide liquidity to permit trading.) If trading houses all figure out how to make money with five digit accuracy, their advantage is not going to be sustained because no one will want to trade with anyone else -- they're all want to take the same positions.
These are a few thoughts. It would be nice to hear from people with digital security and financial trading experience to provide commentary. Thank you.
Tuesday, July 10, 2007
Network Security Monitoring Case Study
I'm now responsible for cleaning up a mid sized company perimeter defences... To be honest, at first glance the task is a daunting one, thousands of users, dozens of dis-separate systems and gigabits of network traffic plus as part of the enterprise support team, I have other projects and duties to deliver on.
I managed to get time with the systems architect and run through a number of questions stolen from your books and other smart folks on the history and state of affairs of my new domain. My questions were answered or put in to context except for one.
"Why don't you have any monitoring tools in place on the edge and perimeter systems?"
The answer I received wasn't what I expected. He simple stated that no-one had the time or energy to take on this massive task. He was very pro about having monitoring, but bluntly realistic on the amount of time monitoring and response took up. The business has other priorities for the IT teams.
It's not that the company isn't security aware, they have good policies, skilled staff, harden systems and layer defences, but no monitoring.
I was stuck with the thought "If I don't understand what's happening on the network, how can I know what's right or wrong, what's normal or abnormal?"
This is exactly right. My friend's co-workers are probably practicing management by belief instead of management by fact. If you do not know for sure what is happening inside your company, how can you make informed decisions? Failure will occur when your luck runs out because you are not spending the time and resources necessary to acquire and maintain digital situational awareness.
I gathered all the documentation, policies and firewall rules together and tried to make sense of them. I re-read Extrusion Detection on my commute in to help me frame a plan of attack. I got all the basic system data of every system, check time and date stamps were all in sync and cleaned up the network maps.
Then, as silly as this seems, the obvious answer came to me on where to start: at the internal firewall internal interface.
I started to review the drop logs of the firewall for that interface, reasoning that if there is a problem on the network, it should more apparent in those logs than anywhere else.
This is also exactly right. There is no need to start buying or building new tools if you are not leveraging your existing data sources or enabling data sources not yet activated.
Those reviews provided some startling results, fortunately for us, the problems were only mis-configured systems attempting outbound access. Mind you, they were generating considerable amounts of traffic and some over already congested WAN links.
Then I laid out the ingress and egress rule sets to find out the motives and owners of those rules in the firewalls and started to peel back those unused or unneeded rule sets, while monitoring the drop logs. All with management approval and sign off, of course!
This is another great move -- a stride towards simplification.
I'm now moving in to the next stage of working with other teams to clean up their problem systems. Some are going to be harder than others as I've found VAX's, AIX, Sun systems and others bouncing off the rules. I haven't seen these types of systems in a long time and as a simple Windows administrator, I have to find time and the right people to plug these holes.
I have a very long way to go, only focused on a very small section of the entire network and no certain path forward on how to apply a reasonable monitoring system - yet :-)
It's a challenge I'm looking forward to and one I'm sure I'll learn from.
The only comment haunting me is the not having any real time allotted to doing monitoring work. I'm going to talk with management and a surprisingly security literate CIO on if this can be addressed.
I know that the conversations have to be based on preventing/mitigating business risk, but believe it's going to be a hard sell with the very long list of other projects being pushed on the team as priority.
If you have any words of advice or useful pointers on convincing them the time is well spent, I'd be grateful.
So this is the major question. How do you convince management or other functional areas that monitoring is important? It sounds to me like my friend has already scored some wins by freeing bandwidth used by misconfigured systems, simplifying firewall rules, and examining individual problematic hosts.
It's important to remember that there is no return on security investment. Security is a cost center that exists to prevent or reduce loss. It is not financially correct to believe you are "earning" a "return" by spending time and money to avoid a loss.
If I need to spend $1000 to hire a guard to protect my $10000 taxi, I am not earning a return on my investment -- I am preventing the theft of my taxi. If I invest that $1000 in a ticketing and GPS system that makes me more productive ferrying passengers (perhaps increasing my dollars per hour worked), then I have enjoyed a ROI once my $1000 expense is covered.
This is not to say that money should not be spent on security. Rather, time and money should be balanced against the perceived risk. The same taxi driver will spend money on insurance, and may indeed need to spend $1000 on a guard if the protection delivered is seen to be necessary. However, the guard does not make the taxi driver more productive. Security is a "business enabler" here but it does not deliver "ROSI."
I'm not a big fan of FUD but something may be happening to executive perception of digital security. I am starting to hear questions like "How do I know that asset X is safe?" or "How do I know that asset Y is not being attacked?" (Answers: "safe" is relative, and Y is being attacked if it's accessible to anyone.)
I don't have any quick answers for my friend, which is why I'm posting this story. What are you doing to convince management that monitoring is necessary? I personally plan to do exactly what my friend did, namely starting with existing assets and showing quick wins to build momentum for more extensive visibility initiatives. You?
Monday, July 09, 2007
More Engineering Disasters
Watching more man-made failures on The History Channel's "Engineering Disasters," I realized lessons learned the hard way by safety, mechanical, and structural engineers and operators can be applied to those practicing digital security. >In 1983, en route from Virginia to Massachusetts, the World War II-era bulk carrier SS Marine Electric sank in high seas. The almost forty year-old ship was ferrying 24,000 tons of coal and 34 Merchant Mariners, none of whom had survival suits to resist the February chill of the Atlantic. All but three died.
The owner of the ship, Marine Transport Lines (MTL), blamed the crew and one of the survivors, Chief Mate Bob Cusick, for the disaster. Investigations of the wreck and a trial revealed the Marine Electric's coal hatch covers were in disrepair, as reported by Cusick prior to the disaster. Apparently the American Bureau of Shipping (ABS), an inspection organization upon which the Coast Guard relied, but funded by ship operators like MTL, had faked reports on the Marine Electric's status. With gaping holes in the coal hatches, the ship's coal containers filled with water in high seas and doomed the crew.
In the wake of the disaster, the Coast Guard recognized that ABS could not be an impartial investigator because ship owners could essentially pay to have their vessels judged seaworthy. Widespread analysis of ship inspections revealed many similar ships and others were unsound, and they were removed from service. Unreliable Coast Guard inspectors were removed. Finally, the Coast Guard created its rescue swimmer team (dramatized by the recent movie "The Guardian") to act as a rapid response unit.
The lessons from the Marine Electric disaster are numerous.
- First, be prepared for incidents and have an incident response team equipped and trained for rapid and effective "rescue."
- Second, be suspicious of reports done by parties with conflicts of interest. Stories abound of vulnerability assessment companies who find all of their clients "above average." To rate them otherwise would be to potentially lose future business.
- Third, understand how to perform forensics to discover root causes of security incidents, and be willing to act decisively if those findings demonstrate problems applicable to other business assets.
Despite the crude state of crash forensics in 1931, the Civil Aeronautics Authority (CAA) determined the plane crashed because its wood wing separated from its steel body during bad weather. TWA, operator of the doomed flight, removed all F-10s from service and burned them. Public pressure forced the CAA, forerunner of today's Federal Aviation Administration, to remove the veil of secrecy applied to its investigation and reporting processes. TWA turned to Donald Douglas for a replacement aircraft, and the very successful DC-3 was born.
The crash of TWA flight 599 provides several sad lessons for digital security.
- First, few seem to care about disasters involving new technologies until a celebrity dies. While no one would like to see such an event occur, it's possible real change of opinion and technology will not happen until a modern Knute Rockne suffers at the hands of a security incident.
- Second, authorities often do not have a real incentive to fix processes and methods until a tragedy like this occurs. Out of this incident came pressure to deploy flight data recorders and more robust aviation organizations.
- Third, real inspection regulations and technological innovation followed the crash, so such momentum may appear after digital wrecks.
Investigators decided to model the entire facility in a computer simulation, then monitor for the highest levels of sunlight over the course of a year. Using this data, 2% of the building's skin was discovered to be causing the reflection problems. The remediation plan, implemented in March 2005, resulted in sanding problematic panels to remove their sheen. The six-week, $60,000 effort fixed the glare.
The lessons from the concert hall involve complexity and unexpected consequences. Architect Frank Geary wanted to push the envelope of architecture with his design. His innovation caused a building that no one, prior to its construction, really understood. Had the system been modeled before being built, it's possible problems could have been avoided. This situation is similar to those involving enterprise network and software architects who design systems that no single person truly understands. Worse, the system may expose services or functionality never expected by its creators. Explicitly taking steps to simulate and test a new design prior to deployment is critical.
Digital security engineers should not ignore the lessons their analog counterparts have to offer. A commitment to learn from the past is the best way to avoid disasters in the future.
Saturday, July 07, 2007
Yet Another Review and Pre-Review
W. Curtis Preston is the king of backups, and his book Backup and Recovery (BAR) is easily the best book available on the subject. Preston makes many good decisions in this book, covering open source projects and considerations for commercial solutions. Tool discussions are accompanied by sound advice and plenty of short war stories. If the author addresses the few concerns I have in his next edition, that should be a five star book.
I also received another book in the mail today, Secure Programming with Static Analysis by Brian Chess and Jacob West. I reviewed drafts of this book and was confident enough of the content to acknowledge involvement. This is part of Gary McGraw's Software Security Series at Addison-Wesley. I liked the last book in that line, Software Security.
Friday, July 06, 2007
ARP Spoofing in Real Life
Thanks to Robert Hensing's pointer to Neil Carpenter's post, I have another documented ARP spoofing attack. Here a malicious IFRAME is injected into traffic by ARP spoofing a gateway. We cover that in my Black Hat class, both of which are now officially full.
Please remember that TCP/IP Weapons School is a traffic analysis class. I believe I cover the most complicated network traces presented in any similar forum. All you need to get the most out of the class is a laptop running a recent version of Wireshark. The class is not about demonstrating tools or having students run tools. Other classes do a better job with that sort of requirement. The purpose of this class is to become a better network security analyst by deeply understanding how certain network-based attacks work. I provide all of the information needed to replicate the attack if so desired, but that is not my goal.
Thursday, July 05, 2007
Another Review, Another Pre-Review
I loved Windows Forensic Analysis (WFA). It's the first five star book from Syngress I've read since early 2006. WFA delivered just what I hoped to read in a book of its size and intended audience, and my expectations were high. If your job requires investigating compromised Windows hosts, you must read WFA.
In the mail today I received a copy of Fuzzing by ninjas Michael Sutton, Adam Greene, and Pedram Amini. H.D. Moore even wrote the foreword, for Pete's sake. However, I have some concerns about this book. I performed a technical review, mainly from the perspective of someone who wants to know more about how to do fuzzing. The drafts I read seemed to be more about how to build a fuzzer. Those of you who are jumping to hit the comment button -- I don't want to hear about "you learn how to fuzz by building a tool." Give me a chance to learn how to walk before I try to invent a new method of transportation! We'll see how the book reads in printed form when I review it.
Wednesday, July 04, 2007
One Review, One Pre-Review
I read Exploiting Software (ES) last year but realized I hadn't reviewed it yet. Having read other books by these authors, like McGraw's Software Security and Hoglund's Rootkits, I realized ES was not as good as those newer books. At the time ES was published (2004) it continued to define the software exploitation genre begun in Building Secure Software. However, I don't think it's necessary to pay close attention to ES when newer books by McGraw and Hoglund are now available.
I'm looking forward to reading Network Warrior by Gary A. Donahue. This book has the second-best subtitle of all of the technical books on my shelves:
Everything you need to know that wasn't on the CCNA exam
I quickly skimmed this book at USENIX and I think it will be valuable. I like books that take nontraditional look at networking issues.
If you're wondering what my favorite subtitle is, it appears in the nearly ten-year-old book The Next World War by James Adams, original founder of iDefense. The book makes silly mistakes (discussing the "Iraqi printer virus") but it was cool to see it talk about the AFCERT and name one of our lieutenants (who was there before I arrived). It was published in 1998 (not 2001 as indicated at Amazon.com) with the subtitle:
Computers are the Weapons and the Front Line Is Everywhere
That is still true today.
Tuesday, July 03, 2007
OpenPacket.org Developments
Please read the rest of the story at the Openpacket.org Blog.
Monday, July 02, 2007
Asset-Centric vs Threat-Centric Digital Situational Awareness
In 2005 invented the term pervasive network awareness (PNA) for my book Extrusion Detection to describe one way to achieve a certain degree of SA:
Pervasive network awareness is the ability to collect the network-based information -- from the viewpoint of any node on the network -- required to make decisions.
PNA is inherently an asset-centric means to improve SA. PNA involves watching assets for indications of violations of confidentiality, integrity, and/or availability (the CIA triad). An asset-centric approach is not the only means to detect incidents, however.
During the past few years several firms have offered services that report indications of security incidents using threat-centric means. These services are not traditional managed security service providers (MSSPs) because they are not watching assets, per se, under the control or operation of a client. In other words, these firms are not placing sensors on company networks and watching for breaches involving monitored systems.
Rather, these next-generation firms seek and investigate infrastructure used by threats to perpetrate their crimes. For example, a threat-centric security firm will identify and analyze the command-and-control mechanisms used by malware or crimeware. The reporting mechanism will be mined for indications of hosts currently under unauthorized control. An example of this is the ongoing Mpack activity I mentioned in Web-Centric Short-Term Incident Containment.
These services improve digital situation awareness by taking a threat-centric approach. The ultimate threat-centric approach would be to monitor activities of the threats themselves, by instrumenting and observing their workplace, communications lines, and/or equipment. Since that is out of the reach of everyone except law enforcement (and usually beyond their reach unless they are extraordinarily lucky and persistent), watching command-and-control channels is the next best bet.
Asset-centric and threat-centric DSA are not mutually exclusive. In fact, threat-centric DSA is a powerful complement to asset-centric DSA. If a company subscribes to a threat-centric DSA service, the service may report that a company system has been compromised and is leaking sensitive data. If confirmed to be true, and if not detected by asset-centric means, the event shows the following:
- Preventative measures failed (since the asset was compromised).
- Asset-centric monitoring failed (since it was not detected).
- Incident response must be initiated (since the compromised asset is not just vulnerable, but actually under the control of an unauthorized party).
With this new understanding, prevention and detection measures can hopefully be improved to reduce the chances of future incidents.
Please do not ask me for recommendations on any of these services; I am not trying to promote anyone. However, I have mentioned two such services before, namely Support Intelligence in Month of Owned Corporations and Secure Science in my review of Phishing Exposed.


text:
Super Street magazine is a great periodical for those who enjoy racing their modified cars. In each issue you will be able to read about the best makes and models for modifying, interesting features, tutorials for modifying your car on your own, technical information, as well as coverage for recent events and upcoming ones. You will enjoy learning more about your hobby through this publication. Order your discount subscription to Super Street magazine today!
Super Street magazine provides you with information about many different makes and models of cars. Regardless of your personal preference, you will find features about cars that you will enjoy reading. You can learn more about the type of car that you enjoy most as well as learn about many different ones. There are articles about Japanese, European, and domestic cars as well as reviews for the newest models on the market. You can even find the latest news in each issue and photos of the hottest vehicles.
How To and Tech
A Super Street magazine subscription also ensures that you have access to valuable information about modifying vehicles. It will be easy for you to make improvements and upgrades on your car once you have this periodical. You will be able to learn about paint, body, chassis, suspension, engine, transmission, drivetrain, interior, electrical, wheels, and tires. Everything that you need is in this publication!
Event Coverage
If you are interested in attending an event or reading about one that has recently transpired, Super Street magazine provides you with the coverage that you desire. In each issue you will be able to read about car shows, motorsports, and even a social feed. Whether you are looking to travel, find a local event, or peruse photos and articles about events from the comfort of your own home, you can do it all with the help of this magazine.
Get ready for your next race by ordering a discount Super Street magazine subscription today!
Magazine covers are used for illustrative purposes only and you may not receive a copy of the particular issue depicted. Your subscription will include the most recent issue once your subscription begins. Magazine covers are the property of the publisher. This site is not officially affiliated with, associated with, or endorsed by Super Street or the publisher.
- Publisher: TEN: The Enthusiast Network

subset: commoncrawl


text:
To view local legislators in your district, please enter your entire address, including apartment number.
Please note: Your personal information will NOT be saved. It will only be used to determine what districts you are in. Thank you.
To improve your search results use quotation marks when searching for a specific phrase.
For example, if you search for substance use, a search WITHOUT quotation marks would find listings that include the words
"substance" OR "use." A search WITH quotation marks ("substance use") would find listings only with the whole phrase "substance use."
Are you sure you want to delete this item?


text:
Reviewed By Kelly R (RENO, NV) Reviewed for a 2010 Toyota Camry —12/25/2015 10:35 PM
I researched numerous intakes for my 2010 Camry SE 2.5 before I decided to buy this item. That being said I chose this intake strictly because of its quality parts, filter, dyno tested numbers and price. Installation was straight forward. The only issues I had we're as follows: The bolt that screws into the bottom of the intake and bracket that hold the intake in place stripped to easy when attempting to install it. i found you don't need it just make sure the hose at the throttle is tight.


text:
Recently, the cameras on board the Cassini spacecraft caught images of meteors racing through the rings of Saturn. Or, rather, photos of the clouds of debris created as the meteors impacted the icy ring particles. These meteors were probably a lot smaller than the Chelyabinsk meteor—-let alone the monsters that rained onto Jupiter—-being perhaps only a yard wide.
The bright streaks visible in the the first pair of Cassini images were photographed in August 2009. They weren't noticed until recently simply because they are so hard to spot. But the large number that have been found is evidence that these are not rare events.
One reason these had not been observed before is that the bright clouds of particles are difficult to see against the background of the equally bright rings. The stand out more distinctly when the sun angle is very low, as it was when these photos were taken. When the sun is almost directly in line with the rings, a cloud of dust rising above the darkened ring plane catches the sun's rays directly. The contrast with the darker background now makes the cloud more easily visible. When the ring background is at its usual brightness, impacts such as these are very difficult to detect.
The impact of these objects, estimated to about 3 feet wide and traveling tens of miles per second, created clouds of tiny particles that were then stretched into long streaks by the motion of the rings.
The image above (click to see full size) shows an impact in the A ring. The streak stretches from the right of the image to the middle, and it does not quite follow the curve of the rings. The brightest part of the streak is over 3000 miles long and 200 kilometers wide (its radial extent, tip to tip) in this image.
The image above (click to see full size) shows an impact into the C ring. This streak is much smaller than the A ring streak, and it appears on the right of the image. The brightest part of this streak is 200 kilometers long (its azimuthal dimension) and 6 miles wide. Scientists estimate that the impact took place about two days earlier. Impact streaks less than a day old have also been discovered in the C ring.
Taken together, these observations confirm of a long-held belief that interplanetary debris continually rains down on Saturn's rings. These constant impacts contribute to the rings' erosion and evolution.


text:
Blaine Mennonite Church (Blaine, Oregon, USA)
Blaine Mennonite Church (Mennonite Church), located seven miles (12 km) east of Blaine, Oregon, was organized in 1956 and in 1959 had 21 members. Jacob D. Kauffman was its pastor.
The congregation disbanded in the late 1970s or early 1980s.
|Melvin Gingerich
|Date Published
Cite This Article
MLA style
Gingerich, Melvin. "Blaine Mennonite Church (Blaine, Oregon, USA)." Global Anabaptist Mennonite Encyclopedia Online. 1959. Web. 18 Sep 2020. https://gameo.org/index.php?title=Blaine_Mennonite_Church_(Blaine,_Oregon,_USA)&oldid=102855.
APA style
Gingerich, Melvin. (1959). Blaine Mennonite Church (Blaine, Oregon, USA). Global Anabaptist Mennonite Encyclopedia Online. Retrieved 18 September 2020, from https://gameo.org/index.php?title=Blaine_Mennonite_Church_(Blaine,_Oregon,_USA)&oldid=102855.
Adapted by permission of Herald Press, Harrisonburg, Virginia, from Mennonite Encyclopedia, Vol. 4, p. 1066. All rights reserved.
©1996-2020 by the Global Anabaptist Mennonite Encyclopedia Online. All rights reserved.


text:
Duke, UNC study: Light is accurate way to identify pre-cancerous cells in esophagus
A device developed by biomedical engineers at Duke University and successfully tested on patients during a clinical trial led by UNC-Chapel Hill holds the promise of being a less invasive method for testing patients suspected of having Barrett's esophagus.
UNC media contact: Tom Hughes, (919) 966-6047, email@example.com
Duke media contact: Richard Merritt, (919) 660-8414, email@example.com
Tuesday, Jan. 4, 2011
CHAPEL HILL, N.C -- Light appears to be an accurate way to identify pre-cancerous cells in the lining of the esophagus.
Developed by biomedical engineers at Duke University and successfully tested on patients during a clinical trial led by the University of North Carolina at Chapel Hill, the device holds the promise of being a less invasive method for testing patients suspected of having Barrett's esophagus, a change in the lining of the esophagus due to acid reflux. Acid reflux occurs when stomach acid splashes, or refluxes, up into the esophagus.
Long periods of such reflux can change the cells lining the esophagus, making them appear more like intestinal cells than esophageal cells. These cellular changes can also be a precursor to cancer. As in most cancers, early identification of these pre-cancerous cells often leads to better outcomes for patients. Barrett's esophagus afflicts more than one percent of the U.S. population, with most patients above the age of 50.
The new system involves the use of a tiny light source at the tip of an endoscope. Physicians shine short bursts of this light at locations of suspected disease along the lining of the esophagus, known as the epithelium. In particular, they are trying to spot characteristic changes within the cells.
"By interpreting the way the light scatters after we shine it at a location on the tissue surface, we can the spot the tell-tales signs of cells that are changing from their healthy, normal state to those that may become cancerous," said Neil Terry, a PhD student working in the laboratory of Adam Wax, associate professor of biomedical engineering at Duke's Pratt School of Engineering, who developed the device.
The team published their findings in the January 2011 issue of the journal Gastroenterology.
"Specifically, the nuclei of pre-cancerous cells are larger than typical cell nuclei, and the light scatters back from them in a characteristic manner," Terry continued. "When we compared the findings from our system with an actual review by pathologists, we found they correlated in 86 percent of the samples."
UNC gastroenterologist Nicholas Shaheen, MD, MPH conducted the preliminary clinical trial of the device on 46 patients with Barrett's esophagus. Shaheen is a professor in the UNC School of Medicine and the UNC Gillings School of Global Public Health and director of UNC's Center for Esophageal Diseases and Swallowing.
"Currently, we take many random tissue samples from areas we where we think abnormal cells may be located," Shaheen said. "This new system may make our biopsies smarter and more targeted. Early detection is crucial, because the cure rate for esophageal cancer that is caught early is quite high, while the cure rate for advanced disease is dismal, with a 15 percent survival rate after five years."
The technology that Wax and his team developed for cancer detection is known as angle-resolved low coherence interferometry (a/LCI). In this process, light is shined into a cell and sensors capture and analyze the light as it is reflected back. The technique is able to separate the unique patterns of the nucleus from the other parts of the cell and provide representations of its changes in shape in real time.
"This optical approach of sampling allows us to cover more tissue sites in less time, and has the potential to significantly improve our ability to spot and monitor these pre-cancerous cells," Wax said. "This type of approach could be used to improve and perhaps one day supplant the physical biopsies currently being used."
Wax pointed out that since approximately 85 percent of all cancers begin within the layers of the epithelium in various parts of the body, he believes that the new system could also work in such cancers as those of the colon, trachea, cervix or bladder.
The research was supported by the National Institutes of Health, the National Science Foundation and Oncoscope, Inc., a company founded in 2006 by Wax based on the Duke technology. Wax has a financial interest in the company, and Terry is a consultant.
Oncoscope plans a clinical trial of the system for Food and Drug Administration premarket approval (PMA), and Wax said there could be a commercially available device as early as 2012.


text:
A lot done, a lot more to do. That could be the Facebook status update for Ananya Mukherjee as she works to establish Vulture Safe Zones (VSZs) to help protect India's remaining vulture populations.
Ananya is the Vulture Safe Zone Coordinator for the Saving Asia's Vultures from Extinction (SAVE) programme organised by the Royal Society for the Protection of Birds (RSPB) – an SOS grantee, who is working to build advocacy for the VSZ concept throughout the sub-continent, engaging with pharmacies, veterinarians, farmers, government officials, policymakers and conservationists alike. Recently, SOS interviewed Ananya over the telephone on one of her annual trips back from the field to RSPB's headquarters in Sandy, UK, to delve into a complex conservation issue.
SOS: What exactly is a Vulture Safe Zone?
The main threat to vultures in India is the poisonous effects on vultures of the drug diclofenac, historically used to treat sick farm animals. The side effects have been especially hard on the Gyps vulture species endemic to the South Asian region in particular the long billed, the slender billed and the white rumpled vulture species. Consequently Vulture Safe Zones (VSZs) work involves ensuring that there is absolutely no diclofenac in a 30,000 sq. km area (or 100 km radius), especially in the food supply of the vultures such as the cattle carcasses that they feed on. Some of these areas will end up being where captive birds can safely be released into the wild.
SOS: Where are the current VSZs in place?
Provisional VSZs had been discussed by experts and authorities back in 2011. By March 2012, three sites had been identified as provisional VSZs - one in Uttarakhand and two in Uttar Pradesh. These areas are colonies where remnant populations of vultures still remain and it is hoped that the vultures would be released back into these natural habitats, eventually. By September 2012, two more provisional VSZs were identified in Gujarat and Assam where work has been initiated as well.
SOS: Can you outline any challenges with managing VSZs?
One of the potential problems in India is that most of these VSZs have a large number of cattle s in the vicinity. This means people owning livestock and cattle need to treat their sick cattle when they are ailing or suffering from old age. Non-steroidal anti-inflammatory drugs (or NSAIDs) are available in the Indian market on a large scale and very cheaply. Many people use diclofenac because it's the most commonly available drug in the South Asian subcontinent. It's cheap and although illegal for veterinary use, unfortunately it's all too readily available as a human drug".
SOS: How do you go about creating VSZs?
Advocacy at government and grassroots level and promotion of meloxicam as a viable alternative. Basically, advocating for a diclofenac-free zone means influencing people's thoughts and opinions to bring about a positive response in not using diclofenac for veterinary purposes. The change was initiated in May 2006 when the Indian Government banned the veterinary use of diclofenac. Unfortunately, the ban did not reach far enough and before long, human forms of diclofenac were used to treat sick cattle. These human forms of the drug are currently being sold by most pharmacies in India with the label 'Not for veterinary use'. Taking legal action against people using diclofenac is difficult when the veterinary form is not commonly sold by pharmacies in India.
The only NSAID drug that can be used on cattle and has been safety tested on vultures is meloxicam. But meloxicam is still not as popular as diclofenac and would require (targeted) hard advocacy and campaigning in the Indian subcontinent from the government to the grassroots level to drive home the point that it does not harm the vultures when they eat cattle carcasses treated with meloxicam. It also requires a ban on the human multi-dose vial size of diclofenac which are being sold in the Indian market and which are often used for veterinary purposes. This is one of the team's priorities: organising targeted awareness programmes and conducting sampling to find out whether diclofenac is being sold by pharmacies or being used by cattle owners to treat their sick cattle.
While Ananya continues to play her role as a catalyst with each VSZ team in India, empowering and enabling them to understand how advocacy work can create momentum is an important aspect of her VSZ work. With gradual awareness and increasing support from all stakeholders, there is hope that the concept of VSZ will gain popularity more widely such that others take similar initiatives and the areas join up across the country. If successful, these VSZs will in the long run be able to provide a safe-haven for nature's undertakers to recover and resume their essential waste disposal activities safe en masse and from harm.


text: Thrust into a life full of woeful twists and turns, Jason Marshall has contended with the prehistoric customs and immeasurable power of the Goreans. His struggles on Gor, a planet resembling Earth, included escaping imprisonment, enslavement, and redeeming lost land. Jason has fought to regain control of his life. Having ascended to a position of power in the Gorean army, Jason must prevail in a battle that seems destined to destroy Gor. Jason has a lot riding on his success as a war leader: prestige, wealth, and an Earth girl of goddesslike beauty. Will Jason be able to win the war and avoid a fate worse than death? Will he be able to find the girl who holds his affections? Will he be able to live as a free man on Earth's counterpart and rise to a still higher position of power and respect?


text:
ICPCSJ07RD - ICC Slim Line Molded Boot Cat5e Patch Cable, 7 ft, Red
Related Categories
Contractors: Get Dealer Pricing Here!
The ICC ICPCSJ07RD Molded Boot Red 7 ft Cat5e Patch Cable is constructed with 4-pair 24 AWG bare copper stranded wire and is 100% tested to the highest performance standards under TIA/EIA-568. These professional grade high performance Cat5e patch cables are UL listed and feature an innovative ultra slim low profile boot that protects the tab and terminations without taking up any extra room.
All ICC ICPCSJ07RD Cat5e Patch Cables are manufactured to the highest standards while constructed with the best materials available. Dont let poorly made inferior Cat5e patch cables cause your network to under-perform! Use high quality Cat5e patch cables to connect all your network devices such as network routers, switches, hubs, computers, or any other devices that attach to a network. The ICPCSJ07RD 7 ft Cat5e patch cables are ideal for any residential or commercial network cabling applications.
Includes: (1) Red 7 ft Cat5e Patch Cable
Performance, Design, and Value
100 % Factory Tested
50 Micro Inch Gold plated contacts
Exceeds ANSI/TIA/EIA-568B.2 connecting hardware requirements
Ultra Slim Low Profile boots for high density applications, no width wasted on boot.
Backwards compatible to all lower rated category components
Constructed with (Ultra Flexible, EZ release, Snag Free Molded Strain relief)
Stranded bare 24 AWG copper wire (no substandard tinned copper materials used)
Safety: UL listed with 94V-0 rated plugs, CSA, CMG, FT4 Flame rated
Part#: ICPCSJ07RD


text:
Alzheimer's disease is the most common form of dementia. It affects a person's memory, thinking, and behavior. It often progresses to the point where it affects daily activities and functions.
According to the Alzheimer's Association, Alzheimer's disease most commonly affects older adults, but it can also affect people in their 30s or 40s. When Alzheimer's disease occurs in someone under the age of 65, it is known as early-onset (or younger-onset) Alzheimer's disease.
Facts about early-onset Alzheimer's disease
About 5 percent of people with Alzheimer's disease have the early-onset form, the Alzheimer's Association says. Many of them are in their 40s and 50s when Alzheimer's disease takes hold.
Types of early-onset Alzheimer's disease
Most types of early-onset Alzheimer's disease are the same, but there are a few small distinctions:
Common Alzheimer's disease. The majority of people with early-onset Alzheimer's disease have the common form of Alzheimer's disease. The disease will progress in roughly the same way as it does in older people with Alzheimer's disease.
Genetic Alzheimer's disease. This form is extremely rare. A few hundred people have genes that directly contribute to Alzheimer's disease. These people begin showing symptoms of the disease in their 30s, 40s, or 50s.
For most people with early-onset Alzheimer's disease, the symptoms will closely mirror those of other forms of Alzheimer's disease.
Early symptoms:
Forgetting important things, particularly newly learned information or important dates
Asking for the same information again and again
Difficulty solving basic problems, such as keeping track of bills or following a favorite recipe
Losing track of the date or time of year
Losing track of where you are and how you got there
Difficulty with depth perception or other vision problems
Difficulty joining conversations or finding the right word for something
Misplacing things and not being able to retrace your steps to find it
Increasingly poor judgment
Withdrawal from work and social situations
Changes in mood and personality
Later symptoms:
Severe mood swings and behavior changes
Deepening confusion about time, place, and life events
Suspicions about friends, family, or caregivers
Difficulty speaking, swallowing, or walking
Severe memory loss
The current diagnosis of early-onset Alzheimer's disease relies on detecting the signs of mental decline noted above. A doctor can then make a diagnosis of Alzheimer's disease with a few tests.
First, the doctor will perform a medical history, and also conduct some cognitive tests of memory, problem-solving, and other mental skills. The doctor might also test your blood, urine, and spinal fluid. Finally, CT and MRI scans of the brain can give the doctor a closer look at your brain tissue to reveal the extent of the damage.
In the future, researchers are hoping that studies on biomarkers will allow experts to diagnose Alzheimer's disease more quickly. Biomarkers are proteins in the body or other types of markers that are a reliable indication of the progress of a disease.
Early-onset Alzheimer's disease currently has no cure. But doctors have had some success in helping people maintain mental function, control behavior, and slow the progression of the disease.
The drugs that are used to help people maintain mental function include donepezil (Aricept), rivastigmine (Exelon), galantamine (Razadyne), and memantine (Namenda). The results have been mixed, but these drugs seem to help people with their symptoms for anywhere from a few months to a few years.
Other therapies that may play a role in slowing the progress of early-onset Alzheimer's disease include physical activity, cardiovascular and diabetes treatments, antioxidants, and cognitive training. A number of studies are ongoing in this area, and researchers are learning new things about Alzheimer's disease every day.
Experts don't know how to prevent Alzheimer's disease, the National Institute on Aging says. Recently, some evidence has shown that detecting the disease early can lead to better treatment options, so it's best to look for any of the early warning signs mentioned above and see the doctor immediately if you notice them.
Managing early-onset Alzheimer's disease
Early-onset Alzheimer's disease can be a difficult disease for people to cope with. The best thing you can do is have a positive outlook and stay as active and mentally engaged as possible.
It's also important to realize that you are not alone. Rely on your friends and family as much as possible. And don't be afraid to seek out a support group if you feel that it might be helpful to you.
When the disease is still in its early stages, it's critical to think about the future. This can include: doing financial planning, working with employers on current and potential job responsibilities, clarifying health insurance coverage, and getting all your important documents in order should your health take a turn for the worse.
Staying healthy
Although Alzheimer's disease has no cure, you can make the best of a bad situation by focusing on keeping your mind and your body as healthy as possible. This can include eating a healthy diet, getting regular exercise, cutting down on alcohol, and using relaxation techniques to reduce stress.


text:
Oops. So we were a little premature in reporting Maria Sharapova's newest outfits back in March. We'd hoped that the blue Nike dress would make a Miami debut. Instead Masha opted to wear Gator colors that week and waited until the French Open to parade this new outfit.
The dress — reminiscent of what Stella McCartney designed for Maria Kirilenko at last year's Wimbledon — can be worn with the black leggings. And Masha did that for her first round match. But she chose to go bare for the second round (photo, left). Yowza!
Also, that embroidered visor is a nice touch.
What do YOU think about the outfit? Tell us.


text:
Go to Disney Land? We must admit, our first reaction to hearing rumors of C. C. being traded was to send Andrew Friedman to his room wihout dessert. With so many talented outfielders in the organization, why trade the one that is arguably the best of the bunch? Well, once we let out a good cry, blew our nose and put the bottle of liquor down, we thought about it some more. Maybe, just maybe, Crawford is the most logical player to trade.
First, let's look at it from the point of view of the teams looking to acquire C. C. Which teams are going to offer the best prospects? Teams that are in playoff contention. Those teams are not looking for a Delmon Young or an Elijah Dukes or a Joey Gathright. Those players are young and unproven at the Major League level. A team making a push for the playoffs needs a bat to fill a hole now, not to fill a hole next season. Rocco Baldelli? Too many question marks with Rocco still. Will he be able to hold up physically, playing everyday? Will he ever regain the speed he had before his injuries? Jonny Gomes? An injured shoulder means he is limited to DH duties.
Now let's look at it from the Devil Rays' point of view. If the team wants to win, it needs pitching, both starters and relievers. All the offense in the world will never make a team a playoff contender if the pitchers can't get anybody out. So what are the team's most valuable chips. There is an obvious surplus of outfielders. So which one? Delmon Young? His stock couldn't be lower right now. Elijah Dukes? A troubled past with tons of potential, means he is more valuable to the Rays than to another organization. Rocco Baldelli? Maybe. He has a payroll friendly contract, but as we stated before, there are too many question marks. Besides, when healthy, and productive, he is probably the most popular Devil Ray. Another extremely popular D-Ray is Jonny Gomes, but the team knows his stock is diminished with his current injury, and there is little to show that he is a capable outfielder even when healthy. That leaves Crawford. He has a payroll friendly contract. He is a proven major leaguer, with plenty of speed and the potential to develop into a 30-30 player. Sounds like the ideal player. Great speed…potential power…could hit .330…still young…signed through 2010…Sounds perfect. So why would a team want to trade Carl Crawford? They wouldn't. So that led us to believe that these rumors were just rumors.
But…then we dug a little deeper. There are rumors of Crawford to the Angels for Ervin Santana. There are also rumors of Crawford to the Rockies. Where are the rumors coming from? To figure that out, you need to know who benefits most from the rumors. The only logical place is that they are being leaked by the Devil Rays' front office. Why? Because the same reasons a team wouldn't trade a player like Carl Crawford is exactly the same reason a team would want a player like Carl Crawford. And if there is a market for Carl Crawford (there is) the way to get the best deal is to turn the situation into a bidding war. C. C. is the sort of player that teams will fight over and fight for.
Crawford is the one player that can command a steep price. In fact, Crawford is the one player that teams may potentially overpay for. Would we hate to see C. C. go? Of course. But we also know that pitching is the key and and there aren't a whole lot of keys in the Devil Rays' organization.
- Crawford could be the next Angel in the outfield. [Sporting News]


text:
Cummins Power Generation Inc., announced a new diesel generator power output ratings category for data center applications. In response to data center customers' needs for assurance of total reliability and dependability, the Data Center Continuous (DCC) rating offers diesel generator sets rated for unlimited hours of operation, with no restrictions on average variable load factor. DCC ratings will be applicable for any data center installation where a reliable utility exists.
The Data Center Continuous ratings span the range of Cummins Power Generation's high horsepower diesel generator sets, from 1 MW up to 2.5 MW, and will apply to both 50 Hz and 60 Hz configurations. This introduction is part of Cummins overall focus on data center innovation, marshalling a team of global experts and life cycle support resources specifically for its data center customers.
Consultants and engineers can now design with the confidence that Cummins DCC ratings can be applied up to the specified rating without restrictions on varying or non-varying loads or hours of operation. The new ratings are in addition to the current emergency standby and prime power ratings. +