I've been in Information Security for the last ten years (Analyst, Architect, Manager, Sr. Manager) and have a CISSP and CISM. I began work in this field immediately out of college. I've been to more Blackhat, Defcon, FIRST, ISACA and SANS conferences than I can count (off the top of my head).
I kind of get what you've written above, and I think you allude to the solution. In the end, Information Security is about Risk Management. Yes, someone could use a needle and inject something into your mustard (I've had that same thought about ketchup; I hate mustard:) ), but the likelihood is so low that there are far more useful things to worry about.
The same with flying on a plane: yep, it could fall like a rock from 34,000 feet. However, the percentage of flights that actually do that is ridiculously low. It's not something to worry about. And I write that having been on a 737 where one of the engines exploded into flame mid-flight. The pilot put the fire out and we landed on the remaining engine; no harm, no foul. I figure my chances are better for that not happening again.
Most IT risks are exactly like that. You have to identify what threats exist and the likelihood that those threats will be realized. Then you implement measures to reduce the most egregious threats to acceptable levels.
Information Security is about managing - not eliminating - risk. In my opinion, thinking about these things has made me smarter (and not more miserable) in my day-to-day decisions. It's not something to get worked up about. These are just facts to consider in dealing with the bigger picture.
I guess my (off-topic) point was that a trillion dollar company is unusual (if not non-existent). The largest publicly held company (by market capitalization) is ExxonMobil and it clocks in at $501.17 billion as of April this year.
Nonetheless, I suspect the OP works for a smaller company if he's the sole one tasked with this project and he's asking Slashdot for help.
The likely goal (from a management perspective) is to establish an authoritative list to allow for efficient management of vulnerabilities. If you know what's out there and "authorized" you can respond to threats far more quickly than otherwise.
Your management would be silly to expect you (unless you are an application analysis company) to thoroughly vet every application that comes through the door. It would be a terrible waste of time.
Do some basic analysis (what ports does it open, does it connect out to other systems, that sort of thing). Beyond that, I believe the value is simply in knowing about the application and being able to track any potential issues.
Not really a new name; the article indicates that this is a re-examination by the same folks who published the study in the 70s to combat the concept that nitrogen was a significant culprity. They wanted to re-emphasize that it's phosphorous that's the real issue and that nitrogen control usually just exacerbates the problem.
Yep - you're right. I must admit that I've seen my fair share of incompetents in that role. Some of the decisions (or lack thereof) I've seen made just boggles the mind.
Have you seriously not worked in a company with a CSO? That's surprising. The last 3 companies I've worked for over the last 10 years have all had a CSO, a CISO, or both.
Not having a function responsible for information security separate from the CIO is, unfortunately, generally a conflict of interest. Too many CIOs focus only on the availability aspect of security.
In my understanding, most sensitive data is stolen from improperly configured applications that permit access to weakly secured databases. See TJX for an example. File permissions have nothing to do with this (except on a very low, irrelevant level).
This is a people problem. People write bad code, configure servers poorly, and manage security inefficiently.
Fully agreed. I used this book as a jumpstart for some of the more obscure functions of the Netscreen firewalls last year. Generally speaking a firewall is a firewall and the GUI is enough to get going. However, there are enough things not exposed (or not intuitively exposed) in the Netscreen GUI to make really digging into the CLI worthwhile. This book helped some with that.
The basic errors in language and presentation, however, detract significantly from the overall experience. I would recommend this book only because it is the only book I've found on the topic that covers it in any detail. The execution is pretty shoddy.
I'm just finishing another technical book which is the exact opposite in terms of execution. "Programming in C" by Stephen Kochan is a great example of how to write a technical book that is relevant, useful, and excellent. The writer for this Netscreen book would be wise to take a few lessons from Kochan.
I completely agree; almost all of these things are 100% true. The land isn't that nice and the weather is never pleasant.
Best not to move out here. Far too many downsides.
I see nothing out-of-the-ordinary here. Looks like the responses were drafted from a typical Democrat's playbook: more government manipulation of policy items that would be better regulated by the open market. Nothing short of a direct attack on individual liberty.
As an Oregonian, I'll be casting my ballot for Smith.
I believe the previous quote would imply, nay insist, that all religions are "state sanctioned". The constitution does not promote the abolishment of religion. Rather it insists on the freedom to worship as one chooses.
The beta argument is bullshit. It's pure deception for Google to call an application half-baked that it is, at the same time, pawning as a SaaS solution for large enterprises:
You're a fool if you do not believe that Google is trying to position this as a replacement for more capable office suites.
There are so many things about Google's approach here that infuriate me (beyond the obvious lack of functionality). As a security consultant, I will _never_ recommend that an organization use this product. Google is a marketing company. The bulk of their revenue is generated by drawing connections between information gleaned from and/or created by it's customers and marketing materials. It is a flat-out conflict of interest to expect Google to be a responsible steward of corporate information stored on it's systems; all of it's infrastructure is designed to mine this information, not to protect it.
The problem is that they don't completely re-flash the firmware. If you have a 1.0.2 unlocked iPhone, the 1.1.1 upgrade will break your baseband and prevent you from making calls or using wi-fi. If they completely reflashed the baseband, that would not be an issue.
No one has yet identified a way to 100% reliably un-do the baseband flash that unlocks the phone. The dev guys say something is coming, but until then those with unlocked phones are out of luck.
Defcon routinely deals with physical security as a subset of the overall program. Last year it was lock-bumping. At least that was somewhat unexpected. A couple of years before that (the last time I attended), there was all kinds of information on lock-picking (a co-worker even purchased a lockpick kit from one of the vendors represented).
None of this is news, and frankly doesn't seem Slashdot-worthy.
Slashdot Mirror
I thought the whole point of the G1 was that it was an open platform. Why on earth is there a "manufacturer-hacker arms race"?
Batzerto was the submitter.
kdawson is a Slashdot administrator.
I've been in Information Security for the last ten years (Analyst, Architect, Manager, Sr. Manager) and have a CISSP and CISM. I began work in this field immediately out of college. I've been to more Blackhat, Defcon, FIRST, ISACA and SANS conferences than I can count (off the top of my head).
I kind of get what you've written above, and I think you allude to the solution. In the end, Information Security is about Risk Management. Yes, someone could use a needle and inject something into your mustard (I've had that same thought about ketchup; I hate mustard :) ), but the likelihood is so low that there are far more useful things to worry about.
The same with flying on a plane: yep, it could fall like a rock from 34,000 feet. However, the percentage of flights that actually do that is ridiculously low. It's not something to worry about. And I write that having been on a 737 where one of the engines exploded into flame mid-flight. The pilot put the fire out and we landed on the remaining engine; no harm, no foul. I figure my chances are better for that not happening again.
Most IT risks are exactly like that. You have to identify what threats exist and the likelihood that those threats will be realized. Then you implement measures to reduce the most egregious threats to acceptable levels.
Information Security is about managing - not eliminating - risk. In my opinion, thinking about these things has made me smarter (and not more miserable) in my day-to-day decisions. It's not something to get worked up about. These are just facts to consider in dealing with the bigger picture.
If you really believe that striving towards the ISO27001 certification is not real InfoSec, then you're in the wrong line of business.
Information Security is not about technology.
I guess my (off-topic) point was that a trillion dollar company is unusual (if not non-existent). The largest publicly held company (by market capitalization) is ExxonMobil and it clocks in at $501.17 billion as of April this year.
Nonetheless, I suspect the OP works for a smaller company if he's the sole one tasked with this project and he's asking Slashdot for help.
Do you know how much a trillion dollars is?
The likely goal (from a management perspective) is to establish an authoritative list to allow for efficient management of vulnerabilities. If you know what's out there and "authorized" you can respond to threats far more quickly than otherwise.
Your management would be silly to expect you (unless you are an application analysis company) to thoroughly vet every application that comes through the door. It would be a terrible waste of time.
Do some basic analysis (what ports does it open, does it connect out to other systems, that sort of thing). Beyond that, I believe the value is simply in knowing about the application and being able to track any potential issues.
Not really a new name; the article indicates that this is a re-examination by the same folks who published the study in the 70s to combat the concept that nitrogen was a significant culprity. They wanted to re-emphasize that it's phosphorous that's the real issue and that nitrogen control usually just exacerbates the problem.
Taco's just being provocative. He's smarter than that.
Yep - you're right. I must admit that I've seen my fair share of incompetents in that role. Some of the decisions (or lack thereof) I've seen made just boggles the mind.
Have you seriously not worked in a company with a CSO? That's surprising. The last 3 companies I've worked for over the last 10 years have all had a CSO, a CISO, or both.
Not having a function responsible for information security separate from the CIO is, unfortunately, generally a conflict of interest. Too many CIOs focus only on the availability aspect of security.
In my understanding, most sensitive data is stolen from improperly configured applications that permit access to weakly secured databases. See TJX for an example. File permissions have nothing to do with this (except on a very low, irrelevant level).
This is a people problem. People write bad code, configure servers poorly, and manage security inefficiently.
This one popped up on my Amazon "recommended" list. I'll definitely be snagging it; the reviews look great.
How is this comment relevant to a book on firewalls?
Fully agreed. I used this book as a jumpstart for some of the more obscure functions of the Netscreen firewalls last year. Generally speaking a firewall is a firewall and the GUI is enough to get going. However, there are enough things not exposed (or not intuitively exposed) in the Netscreen GUI to make really digging into the CLI worthwhile. This book helped some with that.
The basic errors in language and presentation, however, detract significantly from the overall experience. I would recommend this book only because it is the only book I've found on the topic that covers it in any detail. The execution is pretty shoddy.
I'm just finishing another technical book which is the exact opposite in terms of execution. "Programming in C" by Stephen Kochan is a great example of how to write a technical book that is relevant, useful, and excellent. The writer for this Netscreen book would be wise to take a few lessons from Kochan.
1. OP (yours):"This angle of impoverished schools in the Dubya era struck me ..."
2. It's a private school.
I completely agree; almost all of these things are 100% true. The land isn't that nice and the weather is never pleasant. Best not to move out here. Far too many downsides.
I see nothing out-of-the-ordinary here. Looks like the responses were drafted from a typical Democrat's playbook: more government manipulation of policy items that would be better regulated by the open market. Nothing short of a direct attack on individual liberty.
As an Oregonian, I'll be casting my ballot for Smith.
http://wheels.blogs.nytimes.com/2008/01/10/tata-nano-the-worlds-cheapest-car/
I believe the previous quote would imply, nay insist, that all religions are "state sanctioned". The constitution does not promote the abolishment of religion. Rather it insists on the freedom to worship as one chooses.
The beta argument is bullshit. It's pure deception for Google to call an application half-baked that it is, at the same time, pawning as a SaaS solution for large enterprises:
http://www.capgemini.com/google
You're a fool if you do not believe that Google is trying to position this as a replacement for more capable office suites. There are so many things about Google's approach here that infuriate me (beyond the obvious lack of functionality). As a security consultant, I will _never_ recommend that an organization use this product. Google is a marketing company. The bulk of their revenue is generated by drawing connections between information gleaned from and/or created by it's customers and marketing materials. It is a flat-out conflict of interest to expect Google to be a responsible steward of corporate information stored on it's systems; all of it's infrastructure is designed to mine this information, not to protect it.
The problem is that they don't completely re-flash the firmware. If you have a 1.0.2 unlocked iPhone, the 1.1.1 upgrade will break your baseband and prevent you from making calls or using wi-fi. If they completely reflashed the baseband, that would not be an issue.
No one has yet identified a way to 100% reliably un-do the baseband flash that unlocks the phone. The dev guys say something is coming, but until then those with unlocked phones are out of luck.
Defcon routinely deals with physical security as a subset of the overall program. Last year it was lock-bumping. At least that was somewhat unexpected. A couple of years before that (the last time I attended), there was all kinds of information on lock-picking (a co-worker even purchased a lockpick kit from one of the vendors represented).
None of this is news, and frankly doesn't seem Slashdot-worthy.
would require organizations to offer IPv6 for Internet-facing servers
What motivation would an organization have to make this change? Why should they be forced?
This whole transition idea seems naive. Organizations will shift to IPv6 when it's economically beneficial.