Sometimes it takes a little bit of dramatization to get the funding for your security program. Here at IKANHAZFIZMA, well, maybe we take it a bit too far.
Posted in IKANHAZFIZMA | 
2 Comments »
Tags: cashcows • government • lolcats • moneymoneymoney • security
Why sell security software when you can bundle it with pre-installed hardware and operating system and sell it as an appliance? We took some of our best lolcats and put them to work building us something we could “productize” and this is what they came up with….
Posted in IKANHAZFIZMA | No Comments »
Tags: cashcows • lolcats • moneymoneymoney • security • tools
Rybolov’s Note: Hello all, I’m venturing into an open-ended series of blog posts aimed at starting conversation. Note that I’m not selling anything *yet* but ideas and maybe some points for discussion.
Let’s get this out there from the very beginning: I agree with Ranum that full-scale, nation-v/s-nation Cyberwar is not a reality. Not yet anyway, and hopefully it never will be. However, on a smaller scale with well-defined objectives, cyberwar is not only happening now, but it is also a natural progression over the past century.
Looking at where we’re coming from in the existing models and techniques for activities similar to cyberwar, it frames our present state very nicely :
Electronic Countermeasures. This has been happening for some time. The first recorded use of electronic countermeasures (ECM) was in 1905 when the Russians tried to jam radio signals of the Japananese fleet besieging Port Arthur. If you think about ECM as DOS based on radio, sonar, etc, then it seems like cyberwar is just an extension of the same denial of communications that we’ve been doing since communication was “invented”.
Modern Tactical Collection and Jamming. This is where Ranum’s point about spies and soldiers falls apart, mostly because we don’t have clandestine operators doing electronic collection at the tactical level–they’re doing both collection and “attack”. The typical battle flow goes something along the lines of scanning for items of interest, collecting on a specific target, then jamming once hostilities have begun. Doctrinally, collection is called Electronic Support and jamming is called Electronic Attack. What you can expect in a cyberwar is a period of reconnaissance and surveillance for an extended length of time followed by “direct action” during other “kinetic” hostilities.
Radio Station Jamming. This is a wonderful little world that most of you never knew existed. The Warsaw Pact used to jam Radio America and other sorts of fun propaganda that we would send at them. Apparently we’ve had some interesting radio jamming since the end of the Cold War, with China, Cuba, North Korea, and South Korea implicated in some degree or another.
Website Denial-of-Service. Since only old people listen to radio anymore and most news is on the Internet, so it makes sense to DOS news sites with an opposing viewpoint. This happens all the time, with attacks ranging from script kiddies doing ping floods to massive DOSBots and some kind of racketeering action… “You got a nice website, it would be pretty bad if nobody could see it.” Makes me wonder why the US hasn’t taken Al Jazeera off the Internet. Oh, that’s right, somebody already tried it. However, in my mind, jamming something like Al Jazeera is very comparable to jamming Voice of America.
Estonia and Gruzija DOS. These worked pretty well from a denial-of-communications standpoint, but only because of the size of the target. And so what if it did block the Internet, when it comes to military forces, it’s at best an annoyance, at most it will slow you down just enough. Going back to radio jamming, blocking out a signal only works when you have more network to throw at the target than the target has network to communicate with the other end. Believe it or not, there are calculators to determine this.
Given this evolution of communications denial, it’s not unthinkable that people wouldn’t be launching electronic attacks at each other via radar, radio, carrier pigeon, IP or any other way they can.
However, as in the previous precedents and more to some of the points of Ranum’s talk at DojoSec, electronic attacks by themselves only achieve limited objectives. Typically the most likely type of attack is to conduct a physical attack and use the electronic attack, whether it’s radio, radar, or IT assets, to delay the enemy’s response. This is why you have to take an electronic attack seriously if it’s being launched by a country which has a military capable of attacking you physically–it might be just a jamming attack, it might be a precursor to an invasion.
Bottom line here is this: if you use it for communication, it’s a target and has been for some time.
Posted in Technical, The Guerilla CISO, What Doesn't Work, What Works | 5 Comments »
Tags: cashcows • cybercommand • cybercorps • Cyberwar • government • infosec • infosharing • itsatrap • moneymoneymoney • pwnage • risk • security
So I was doing my usual “Beltway Bandit Perusal of Opportunities for Filthy Lucre” also known as diving into FedBizOps and I found this gem. Basically what this means is that sometime this summer, NIST is going to put out an RFP for contractors to further develop SCAP using ARRA funds.
Keeping in mind that this isn’t the official list of what NIST wants done under this contract, but it’s interesting to look at from an angle of where SCAP will go over the next couple of years:
So how do you play? Well, the first thing is that you respond to the notice with a capabilities statement saying “yes, we have experience in doing what you want”–there is a list of specifics in the original notice. Then sign up for FedBizOps and follow the announcement so you can get changes and the RFP when it comes out.
Posted in NIST, Outsourcing | 5 Comments »
Tags: 800-53 • fisma • infosec • infosharing • management • metrics • moneymoneymoney • NIST • scalability • scap • security
Check out this blog post. Wow, all sorts of crazies decend out of the woodwork when Bruce talks about something that’s been around for years and suddenly everyone’s redesigning the desktop from the ground up.
Quick recap on comments:
Proving once again that you can’t talk about Windows desktop security without it evolving into a flamewar. Might as well pull out “vi v/s emacs” while you’re at it, Bruce. =)
Computer Setup photo by karindalziel. Yes, one of them is a linux box, I used this picture for that very same reason. =)
But there is one point that people need to understand. The magic of FDCC is not in the fact that the Government used its IT-buying muscle to get Microsoft to cooperate. Oh no, that’s to be expected–the guys at MS are used to working with a lot of people now on requests.
The true magic of FDCC is getting the application vendors to play along. To wit:
In other words, if your software works with FDCC, it’s probably built to run on a security-correct operating system in the first place. This is a good thing, and in this case the Government is using its IT budget to bring the application vendors into some sort of minimal security to the rest of the world.
This statement is from the FDCC FAQ, comments in parenthesis are mine:
“How are vendors required to prove FDCC compliance?
There is no formal compliance process; vendors of information technology products must self-assert FDCC compliance. They are expected to ensure that their products function correctly with computers configured with the FDCC settings. The product installation process must make no changes to the FDCC settings. Applications must work with users who do not have administrative privileges, the only acceptable exception being information technology management tools. Vendors must test their products on systems configured with the FDCC settings, they must use SCAP validated tools with FDCC Scanner capability to certify their products operate correctly with FDCC configurations and do not alter FDCC settings. The OMB provided suggested language in this memo: http://www.whitehouse.gov/omb/memoranda/fy2007/m07-18.pdf, vendors are likely to encounter similar language when negotiating with agencies.”
So really what you get out of self-certification is something like this:
Posted in Technical | 4 Comments »
Tags: cashcows • certification • compatibility • compliance • fdcc • government • infosec • moneymoneymoney • NIST • omb • scalability • scap • security
Rybolov Note: this is part 4 in a series about S.773. Go read the bill here. Go read part one here. Go read part two here. Go read part three here. Go read part four here.
Themes: I’ve read this thing back and forth, and one theme emerges overall: We’ve talked for the better part of a decade about what it’s going to take to “solve” this problem that is IT security, from an internal Federal Government standpoint, from a military-industrial complex standpoint, from a state and local government standpoint, from a private-sector standpoint, and from an end-user standpoint. This bill takes some of the best though on the issue, wraps it all up, and presents it as a “if you want to get the job done, this is the way to do it”.
Missing: The role of DHS. Commerce is highly represented, over-represented to my mindset. Looking at the pieces of who owns what:
Commerce security organizations:
NTIA–Technically not a security organization, but they manage the DNS root and set telecom policy.
NIST–They write the standards for security.
FTC–They regulate trade and have oversight over business fraud.
DHS Security organizations:
NPPD–They are responsible for critical infrastructure and national risk management.
NCSD–They do the security operations side of our national cybersecurity strategy and run US-CERT. (BTW, hi guys!)
Secret Service–They have the primary responsibility of protecting the US Currency which also includes computer crimes against financial infrastructure.
Science and Technology Directorate–They are responsible for research and development, including IT security.
DOJ Security Organizations:
FBI–Surprise, they do investigations.
So you see, some of the things that are tasked to Commerce are done by DHS and DOJ. This is probably the nature of the bill, it was introduced in the Commerce committee so it’s understandable that it would be Commerce-centric.
Cost: One thing kept nagging me in the back of my head while going through this bill is the cost to do everything We’re asking to do a lot in this bill, now what’s the total cost? Typically what happens when a bill makes it out of committee is that the Congressional Budget Office attached a price to the legislation as far as the total cost and then what’s the breakdown for the average American household. That data isn’t published yet on the bill’s page, so we’ll see in the next iteration.
In-Your-Face Politics: Really, this bill is showing us how to do the full security piece. It includes everything. It’s challenging people to come up with alternatives. It’s challenging people to delete the sections that don’t make sense. It’s challenging people to fix the scope issues. Like it or hate it, it definitely stirs up debate.
Final Thoughts: S.773 is a pretty decent bill. It has some warts that need to be fixed, but overall it’s a pretty positive step.
Capitol photo by bigmikesndtech.
Posted in Public Policy | No Comments »
Tags: cashcows • comments • dhs • government • infosec • infosharing • itsatrap • law • legislation • management • moneymoneymoney • NIST • publicpolicy • risk • S773 • scalability • security • stategovernment
« Previous Entries Next Entries »
Posts RSS
Subscribe via Email