Emulate some Cisco routers on your laptop using Dynamips. This looks awesome! From Andrew Hay.

Holy crap 9600 baud is slow! I’m doing something different in loading a wiped switch, and I thought I would use an xmodem transfer. Go me! Since this is taking so long, I may as well post some switch basics as I go. (To note, my earliest speeds on the Internet were 14.4kbps modems back in high school.) I’ll also go ahead and put on some background music, the excellent Dubnobasswithmyheadman album from Underworld (a favorite!).

I have a completely wiped Cisco Catalyst 2950T switch. Even the flash has been erased (an eraser of love). If you boot it up, it gives an error and stops pretty quickly. A quick “dir flash:” will show nothing. I also have an ios version ready and waiting: c2950-i6k2l2q4-mz.121-22.EA8a.bin. For my console system I have an old Dell Latitude laptop (yeah, it’s one sexy-small laptop!) running a permanent install of BackTrack2.

To get the c2950-i6k2l2q4-mz.121-22.EA8a.bin file to BackTrack2, I decided to also test my tftp server and use tftp to transfer the file. My tftp server is at 192.168.10.108.

tftp 192.168.10.108 -c get c2950-i6k2l2q4-mz.121-22.EA8a.bin

Gosh, that’s easy. Now I need to connect up to the switch by plugging in necessary cables, including the power so that it powers on and loads. I decide to use CuteCom in BackTrack2 as my graphical terminal emulator. I change the baud rate to 9600 and click Open device. I type a few commands to get ready for my transfer.

switch: flash_init
Initializing Flash…
…The flash is already initialized.
switch: load_helper
switch: copy xmodem: flash:c2950-i6k2l2q4-mz.121-22.EA8a.bin
Begin the Xmodem-1k transfer now…

At this point the terminal is waiting for some data. CuteCom has a Send File button at the bottom where I can select the file and start transferring at the blistering 9600 speed! In fact, after writing this, I’m still only up to 15% completed. Ahh the joys of a wiped device that doesn’t even know what an IP address is yet.

Articles like this one about DHS looking to investigate a government security contractor illustrate some of the crap (normal business activity) that occurs in our industry. I’m not going to presume I know the full story or what was in the original contract or what Unisys’ opinion is, but I think this article illustrates two painful realities.

1. If DHS is attacked and they have someone to blame such as a contractor who should be taking care of things, the blame can and likely will be shifted, rightfully or not. This basically means the “information age” is not just surging along and pulling culture with it, but business culture is requiring information be saved and documented to avoid he-said-she-said crap. So unless Unisys goes the proverbial extra mile in the contract and also documents all deviations or obstacles, and because security will always eventually fail, there will always be a scapegoat. And blaming everyone else for responsibility for things is a hallmark of the 90s and 00s. (All starting with the McDonald’s woman who spilled hot [no shit?!] coffee on herself and successfully sued.)

2. The government is opening up competing bids for the contract. That means we have a major differentiator being cost/price. And we all can guess how the quality of security may follow the line of price. Lowest bid will almost certainly ensure the security is also of lower quality.

I’ve been checking out theJericho Forum commandments (pdf) and their concept of de-perimeterization. I’m happy to have taken the time to sit back and examine their material posted. Whether I agree or not, it is useful to examine discussion and what other groups think.

1) I stand by my intial thoughts that the concept of “de-perimeterization” is old. I really bet this concept is rooted back in a time before deep inspection firewalls, and maybe even before stateful firewalls. The term is unfortunate and likely needs to be changed, unless they are using it just for the attention. If so, it works! 🙂 But otherwise, I don’t buy that de-perimeterization is the future. Sure, maybe borders of yesterday were nice and square like the state of Colarado. But today and maybe into the future our borders will be more complicated like the islands of the Nunavut Territory in Canada (am I the only one who missed the Northern Territories being split? And does that mean I don’t know my geography? …the flaw in quizzing adults about geography and generalizing the result down into child education values…). Nonethless, there are still borders and we will always have a perimeter of some sort for as long as we need any type of centralization management of systems or data.

2) The commandments do make for an excellent ideal. A possibly unattainable ideal. I’m dubious about the scale of such solutions, and I really think this framework only works on a very large scale. Anything below it really can’t be bothered.

3) On the other hand, this framework does include excellent guidelines and “rules.” Even if they are not followed to a letter, they are rooted in solid digital security concepts. We should keep them in mind no matter what ultimate framework we follow.

4) Likewise, I really think all security professionals should review what the Jericho Forum is saying, and I’d love to attend a presentation some day for even more clarification and discourse. As sec pros, we should be able to discuss such things and keep an open mind about other viewpoints. Besides, if there was an ultimate and perfect solution to our problems, I’m guessing we’d have happened upon it by now and all been wowed to the point of tears. But we’re not, and as such, any and all approaches tend to have strong points and good ideas.

5) In the end, do I care about this framework itself? Not really. It’s a great exercise, but not really actionable for me in a smaller company beyond just being informed.

jericho 1 – de-perimeterization and the jericho forum commandments
jericho 2 – the jericho forum and the de-perimeterization solution
jericho 3 – the first three commandments: the fundamentals
jericho 4 – commandments 4 – 8
jericho 5 – commandments 9-11
jericho 6 – my conclusions

Continuing my smallish review on the Jericho Forum commandments (pdf) and their concept of de-perimeterization, I have just three commandments left, all under the category, “Access to data.”

Access to data should be controlled by security attributes of the
data itself

– Attributes can be held within the data (DRM/Metadata) or could be a separate system
– Access / security could be implemented by encryption
– Some data may have “public, non-confidential” attributes
– Access and access rights have a temporal component

This sounds like a Mandatory Access Control system where data contain attributes which determine access and use. This is a bit odd, since I have only heard of this system used by governments (classified, unclassified, top secret…).

This also sounds like DRM, which, nicely enough, is mentioned by term in the bullets! One problem with DRM and metadata is forcing adherence to the metadata or DRM (let’s call it collectively DRM for my own sake). What if you have metadata that dictates FileX should only be used by 15 people. What if I come in and read FileX but decide to ignore the DRM tags? Is this another form of encryption? Why can’t I just leverage the DRM to get the data and then move it elsewhere as a copy? Sounds familiar? It should, since we’re seeing how useful or futile DRM processes can be with media and copyright.

MAC has worked for the government and military for a long time, but I think that has to do with a) the rigid discipline of the military and secret organizations, and b) the long-term habitual, forced use of it. Can this be as rigid and forced globally? At this point in time, I can’t see that happening in the foreseeable future.

Overall, oddly, I do like this commandment. Even if I don’t buy into the specified mechanics, I agree we need to focus on data. Not to the exclusion of the network or systems, but focusing on the data needs to be part of the security equation.

Data privacy (and security of any asset of sufficiently high value)
requires a segregation of duties/privileges

– Permissions, keys, privileges etc. must ultimately fall under independent control, or there will always be a weakest link at the top of the chain of trust
– Administrator access must also be subject to these controls

Hoo-boy..this is a tough one. This commandment pretty much ensures that data protection solutions will be complex. Ultimately, you do need someone who turns the keys when it comes to protection. Maybe two people, or three, but someone somewhere will either have the power or a collusion of forces will have the power. And that’s in extremely complex setups for separation of duties/privs.

But even if this commandment is complex and maybe ultimately not of interest or achievable to most organizations, this is a good guideline to try to achieve. Most everyone has domain admin credentials and a need to create accounts in an organization. These tasks/privs can be separated to various people with various auditing and authorization chains.

Is this scalable for small companies with 1 IT person, or even medium-sized companies? Good question, and likely not. Even in my current team of 5 network guys and 3 desktop guys, we really don’t have the corporate interest in slowing down our processes to achieve this idea ultimately. We do so for a couple tasks and privileges, but otherwise it is just not worth our time to figure out.

By default, data must be appropriately secured when stored, in
transit and in use

– Removing the default must be a conscious act
– High security should not be enforced for everything; “appropriate” implies varying
levels with potentially some data not secured at all

In other words, default should be secure. If you want it less secured, you have to choose to unsecure it, or back down on the security controls to an appropriate level. Sounds good to me, although I think this commandment is much more attainable in closed networks, i.e. networks with boundaries.

Oh, wait, hold on…did I say networks with boundaries? Yup! Networks with perimeters! Without perimeters…well, that means either the whole Internet needs to run on new protocols (which I believe the Jericho Forum would like to see happen) or we need a global IPSec (or encryption/PKI) setup that is trusted by all. Ack.

Of interest, it seems this is the only commandment that allows some leniency. Someone determines what is appropriate, rather than blanket, rigid statements like most of the other commandments. Quite interesting to have a subjectivie commandment in here, but still appropriate.

jericho 1 – de-perimeterization and the jericho forum commandments
jericho 2 – the jericho forum and the de-perimeterization solution
jericho 3 – the first three commandments: the fundamentals
jericho 4 – commandments 4 – 8
jericho 5 – commandments 9-11
jericho 6 – my conclusions

Sending emails with PowerShell is pretty straightforward. Emails can be sent either by default through a normal SMTP server or they can be dumped into a local instance of IIS to be picked up and delivered. Both can be useful depending on the situation.

First, I want to prove I can send email from my workstation through the fictious mail server at mail.server.com. Each of the .Send method arguments can be string variables if needed.

$smtp = new-object Net.Mail.SmtpClient(“mail.server.com”)
$smtp.send(“mike@server.com”,”mike@server.com”,”test”,”test”)
$smtp

Host : mail.server.com
Port : 25
UseDefaultCredentials : False
Credentials :
Timeout : 100000
ServicePoint : System.Net.ServicePoint
DeliveryMethod : Network
PickupDirectoryLocation :
EnableSsl : False
ClientCertificates : {}

This next example dumps the email to the local IIS instance. Just change the DeliveryMethod and then send the email as normal.

PS> $smtp = new-object Net.Mail.SmtpClient
$smtp.DeliveryMethod = “PickupDirectoryFromIis”
$smtp.send(“mike@server.com”,”mike@server.com”,”test”,”test”)
$smtp

Host :
Port : 25
UseDefaultCredentials : False
Credentials :
Timeout : 100000
ServicePoint : System.Net.ServicePoint
DeliveryMethod : PickupDirectoryFromIis
PickupDirectoryLocation :
EnableSsl : False
ClientCertificates : {}

I consider this a major part of scripting of any type: notifications. It is not necessarily enough to just log something if you never check logs. I’d rather throw something to the foreground, which includes an actual error, or in the case of a daily notification that a script has run, a quick email to my Inbox. This can even complement logs, such as with a log tail script that emails on certain events. Among many, many other uses.

Jericho…commandments…yeah, I can see the searches that drag people here now…great. I’m continuing my look at the commandments from the Jericho Forum. This is commandment 4 which bears the header, Surviving in a Hostile World.

Devices and applications must communicate using open, secure
protocols

– Security through obscurity is a flawed assumption – secure protocols demand open peer review to provide robust assessment and thus wide acceptance and use
– The security requirements of confidentiality, integrity and availability (reliability) should be assessed and built in to protocols as appropriate, not added-on

– Encrypted encapsulation should only be used when appropriate and does not solve
everything

Oh boy! We hit some tender spots here! I think the assumption about using open protocols is that the more open something is the more secure. I guess if you fully believe in a strict interpretation of the first bullet point, this makes sense. But I find it a dubious claim to accept across the board. They have a point about things being open. Take Skype for instance. I dislike Skype because I have no idea what their encryption consists of because it is not open. Still, I can accept this commandment as part of an ideal framework, but I don’t think that reflect reality.

I don’t like bullet 1 at all. Security through obscurity is life; deal with it. Security through obscurity alone is not security. That’s the proper usage of that phrase. Utilizing obscurity can reduce your risk. Changing the SSH server port to TCP 23412 will lower your risk, but true, it won’t increase the inherent security of the SSH server itself. So strictly speaking, I don’t buy this bullet point. Also, there are times where if we opened up a protocol to peer review and acceptance, we’ll spend 25 years over-analyzing and trying to provide a consensus, and then look back at the bloated monster of a protocol that results. Yikes.

The second bullet makes me think what we’re hoping for are god-like tentacles of protocols on the Internet. I just don’t think that is going to work. We need simple, small, extensible protocols. They should be solid, scalable, and work well. Confidential? I don’t quite buy that…and I’m interested in security. Take the simple building blocks and secure them. I don’t know what bullet three is referring to, so I’ll skip that one.

All devices must be capable of maintaining their security policy on
an untrusted network

– A “security policy” defines the rules with regard to the protection of the asset
– Rules must be complete with respect to an arbitrary context
– Any implementation must be capable of surviving on the raw Internet, e.g., will not
break on any input

Again, I get the feeling we’re striving for a framework no one can attain. That’s not a good goal. This commandment sounds good on one hand, but one bullet and one implication make this taste bitter.

First, I agree that devices need to maintain their security when away from the nest. My caveat comes when a security policy needs to be updated or changed. What then? Does this not mean a digital form of sneakernet or centralized management? This makes me feel like our devices all need to be like H3 Hummers; tanks driving around the big bad roadways. Ugh.

The first two bullets are no-brainers. The third bullet sounds nice, until that last little bit. Will not break on any input. Well, that’s great. Again, a nice ideal, but trying to build perfect devices and security by using imperfect people is a stretch for me.

Next, I’m blocking commandments 6-8 into one section since they seem to cover similar ground.

All people, processes, technology must have declared and
transparent levels of trust for any transaction to take place

– Trust in this context is establishing understanding between contracting parties to conduct a transaction and the obligations this assigns on each party involved
– Trust models must encompass people/organisations and devices/infrastructure
– Trust level may vary by location, transaction type, user role and transactional risk

Mutual trust assurance levels must be determinable

– Devices and users must be capable of appropriate levels of (mutual) authentication for accessing systems and data
– Authentication and authorisation frameworks must support the trust model

Authentication, authorisation and accountability must interoperate / exchange outside of your locus / area of control

– People/systems must be able to manage permissions of resources and rights of users they don’t control
– There must be capability of trusting an organisation, which can authenticate individuals or groups, thus eliminating the need to create separate identities
– In principle, only one instance of person / system / identity may exist, but privacy necessitates the support for multiple instances, or once instance with multiple facets
– Systems must be able to pass on security credentials /assertions
– Multiple loci (areas) of control must be supported

I’m not really sure how to take these three commandments. It sounds like it would be satisfied with a global identification and trust system. That would certainly be fairly perimeterless! But that will never happen, especially in the US. In fact, it is that third bullet, about having trust levels varying, that make me still believe there are perimeters. When a trust level changes, that’s where you put some access control. Network access control. Anyway, I can’t be too dogged on these three commandments since I don’t fully get it.

So what we have so far is very heart-warming, feel-good idealistic goals for a global infrastructure (extrastructure?) utilizing perfect or near perfect protocols and devices that can withstand anything. Sorry, but what the fuck…?

jericho 1 – de-perimeterization and the jericho forum commandments
jericho 2 – the jericho forum and the de-perimeterization solution
jericho 3 – the first three commandments: the fundamentals
jericho 4 – commandments 4 – 8
jericho 5 – commandments 9-11
jericho 6 – my conclusions

Mark Curphey has begun a series of posts about scoping application security reviews. Part 1 talks about the business of application security reviews. Part 2 talks about the types of testing. They’re good reads, and I’m looking forward to the other parts.

I previously figured out how to start a PowerShell script from within another script. My next requirement was to start another script that required a variable. This took some trial and error to figure out the arguments need to be outside the quotes.

& “d:\scripts\installwebserver.ps1” SERVERNAME

As I was talking to a colleague yesterday about the Jericho Forum, someone who didn’t know about them, it occured to me how “European” this approach is. I guess it might be more accurate to say it is not terribly compatible with typical American approaches. In the US, we hold capitalism and competition very dear. So dear, that we typically choose competition over cooperation. The attitude is “I can do it better and make money,” as opposed to “what is best?” The Jericho Forum suggestions greatly smack of the latter. For this reason, I’m not sure the US will ever adopt this early, if ever. Great at innovating! Poor at maturing those innovations.

Moving on to the actual Commandments from the Jericho Forum, I first see they are bookended by some textspeak. This occurs at the beginning:

The Jericho Forum commandments define both the areas and the principles that must be observed when planning for a de-perimeterized future.
Whilst building on “good security”, the commandments specifically address those areas of
security that are necessary to deliver a de-perimeterized vision.
The commandments serve as a benchmark by which concepts, solutions, standards and systems can be assessed and measured.

And this occurs at the end:

Conclusion
De-perimeterization has happened, is happening and is inevitable; central
protection is decreasing in effectiveness

– It will happen in your corporate lifetime
– Therefore you need to plan for it and should have a roadmap of how to get there
– The Jericho Forum has generic roadmap to assist in the planning

First, the Jericho Forum hasn’t led me to conclude these things. Second, I understand this is not a wholistic roadmap to security, but rather a security framework intended to address de-perimeterization. That’s a slight cop-out, but ok, I’m willing to accept this.

So, here are the first three commandments, grouped as the Fundamentals.

The scope and level of protection should be specific & appropriate
to the asset at risk

– Business demands that security enables business agility and is cost effective
– Whereas boundary firewalls may continue to provide basic network protection, individual systems and data will need to be capable of protecting themselves
– In general, it’s easier to protect an asset the closer protection is provided

The commandment itself is sound, and an extremely common business theme. Same as the first bullet point. I can agree with these outright. The second bullet point, however, gets back to my current non-acceptance of their hypothesis, and as such I’m predictably cautious. I don’t know that data should be capable of protecting itself. Since this is tied to the hypothesis, I’ll skip it for now. The last bullet point is also dubious. I counter that it is easier to protect assets close when you have a) few assets or b) strong centralized administration of those security controls. But wait…that appears counter to de-centralization everything. Oops! I’d rather not manage 4000 laptops individually like so many isolate islands. This bullet point is a big step back.

Security mechanisms must be pervasive, simple, scalable & easy to
manage

– Unnecessary complexity is a threat to good security
– Coherent security principles are required which span all tiers of the architecture
– Security mechanisms must scale; from small objects to large objects
– To be both simple and scalable, interoperable security “building blocks” need to be
capable of being combined to provide the required security mechanisms

This second commandment is another no-brainer, although sometimes non-scalable solutions are fine for a company that is not intending to grow out of the solution scale in the lifetime of that solution. Enterprise-level solutions don’t necessarily apply to small companies. The other three descriptors are obvious and I do like the commandment itself.

The first bullet point is something that is not mentioned enough, and too often is mentioned as a baseball bat to get your way of doing things. It’s a largely non-actionable topic, but it really does matter. Complexity means less people understand what is going on, flaws can occur in the middle of all that complexity, it is not agile, often not scalable, and so on. Sadly, “complex” is a relative term which no one agrees upon except in general principle. The second bullet point says the same thing only inversely: keep things easy to understand. Well, yeah, hopefully!

The third bullet point is part of my minor quibble on this commandment. I don’t think everything must scale. This is determined by the company. If this is meant as a framework for the whole world, then yes, I sure would hope solutions are scalable.

The fourth bullet is one I’d love to hear more about as I think I can read it many different ways. Building blocks…like simple components which together form a secure puzzle? Does that affect complexity? Does each building block need to not only be functional but also secure as part of the inherently secure protocols and such? This almost sounds like a “feel good” bullet point that really means nothing and therefore cannot be addressed at all.

Assume context at your peril

– Security solutions designed for one environment may not be transferable to work in another. Thus it is important to understand the limitations of any security solution

– Problems, limitations and issues can come from a variety of sources, including geographic, legal, technical, acceptability of risk, etc.
– Surviving in a hostile world

The first bullet point on this third commandment seems to address my concern above, about solutions being different for different organizations. Likewise, homegrown apps or ways of putting things together in one environment, may not be transferable directly to some other network. That’s fine, but doesn’t that undercut needing scalability and simplicity? I guess this gets down to, “Is security a commodity product or a customized service?” By having a framework for everyone, I would also follow that with this describing a commodity product. The second bullet supports the first.

The third bullet…eh? I think someone needs to reword that. This commandment and the third bullet mean little alone.

Of note, I really like what “Assume context at your own risk,” says to me. It reminds me of things I see on mailing lists repeatedly. A vague security questions answered by 10 people 10 different ways, all of which make assumptions or contextual decisions without really properly asking questions or answering the actual question. Things are different everyone, and we must not assume it is all the same, but instead interrogate stakeholders. Oddly, I don’t get the bullet points for this.

jericho 1 – de-perimeterization and the jericho forum commandments
jericho 2 – the jericho forum and the de-perimeterization solution
jericho 3 – the first three commandments: the fundamentals
jericho 4 – commandments 4 – 8
jericho 5 – commandments 9-11
jericho 6 – my conclusions

I’m going to continue looking at the Jericho Forum’s concept of de-perimeterization (god, that’s a bitch to type…) and its commandments. In this “chunk,” I’m taking the “de-perimeterization solution” section of their main page.

While traditional security solutions like network boundary technology will continue to have their roles, we must respond to their limitations. In a fully de-perimeterized network, every component will be independently secure, requiring systems and data protection on multiple levels, using a mixture of:

I like that they concede that boundary technology will continue to have their roles. They don’t stress this enough to address the knee-jerk reaction they get of “oh my god they want us to remove our firewalls!” Sadly, they follow this up with saying every component needs to be independently secure. Ugh…why bother with the first statement, then? Is that network boundary only good for logging now? I think this is a great goal, however, but it should be the juxtaposition of these two ideas: strong boundary with strong systems. This is called defense in depth, which Jericho Forum is seemingly avoiding in exchange for their more dramatic “de-perimeterization” term.

-encryption
-inherently-secure computer protocols
-inherently-secure computer systems
-data-level authentication

That first item is good, but it definitely is a fly in being able to monitor your networks. The role of encryption alone is powerful enough to shape the direction of security for the coming 50 years. They have a big point with this, and if it continues, the effect will be a de-perimeterization for deeper level attacks which we just won’t be able to decrypt and inspect without each system becoming an island fortress. Yikes!

The middle two…just make me sigh in bliss. I wish we could do that, but it won’t happen. Even things we think are inherently secure today have holes found years from now. This is an ideal, and just won’t happen because we’re not perfect, but more importantly because it is not economical for most of business. The software and web developer industries are excellent illustrations that there is not enough drive to get things secure up front. The drive is to get things done first, prove that it can make the company money, and later scramble for an SDLC that includes security testing and design near the start. Unless the world turns topsy-turvy in the next 50 years, I just can’t see this changing; it’s a basic effect of technology, progress, and change.

I’m not sure what is meant by “data-level authentication.” Does this mean the data will inherently authenticate users accessing it? I can only guess at this one. It sounds catchy, but could be just empty speak.

The design principles that guide the development of such technology solutions are what we call our “Commandments”, which capture the essential requirements for IT security in a de-perimeterized world.

Great!

jericho 1 – de-perimeterization and the jericho forum commandments
jericho 2 – the jericho forum and the de-perimeterization solution
jericho 3 – the first three commandments: the fundamentals
jericho 4 – commandments 4 – 8
jericho 5 – commandments 9-11
jericho 6 – my conclusions

Hoff recently struck a banner in the ground defending the Jericho Forum’s concept of de-perimeterization (alebit not the FUD version) and their commandments (pdf). I typically respect what Hoff has to say (when I understand the topic!), so I decided to stick my nose a bit deeper into the Jericho Forum’s position and commandments while trying to keep an open mind. I might just learn something!

First in my examination is checking out their front page which explains de-perimeterization. With such a bold placement, this better be the meat of their message; the why and the what. This also turns out to be the place people create first impressions. Let’s chunk this a bit.

today the traditional “firewalled” approach to securing a network boundary is at best flawed, and at worst ineffective. Examples include:

-business demands that tunnel through perimeters or bypass them altogether
-IT products that cross the boundary, encapsulating their protocols within Web protocols

-security exploits that use e-mail and Web to get through the perimeter.

This is stating the obvious, yup, business demands tunnel through barriers, products tunnel through already-trusted protocols, and there is insecurity inside the contents of those protocols. Nothing new here for anyone who has been in IT at any time in the last 10 years. Besides, isn’t this the point of internetworks, to share through barriers?

Of course, the point of these barriers is to let certain things through and not let others through. Just because a few holes are poked doesn’t mean the barrier is useless. If I put doors to my office with a card reader to slow down the press of bodies to get to work in the morning so my guards can keep a visual for suspicious people, should I get rid of those doors because I’m letting people through already? No.

The Jericho Forum has a point when it tackles tunneling “stuff” through the web protocols which are allowed anyway. I guess we can assume no perimeter devices will deeply inspect packets. But still, I see nothing here that truly suggest the “firewalled” approach is either ineffective or flawed, at least by today’s firewall standards.

IT IS DANGEROUS TO ASSUME THAT A SECURITY MEASURE MUST EITHER BE PERFECT OR IS OTHERWISE USELESS! That is the message I get when they call firewalls ineffective or flawed. This just means you need deeper inspection or layered defenses. It is dangerous to say we have a trend of de-perimeterization just because we allow talk between networks.

to respond to future business needs, the break-down of the traditional distinctions between “your” network and “ours” is inevitable

This is pure semantics and means nothing. It’s a literary method equivalent to taking a data set in statistics and making it paint a glass half full or glass half empty picture just by playing with the numbers. Besides, I don’t think anyone in any company *doesn’t* think about “their” network and “everything else.” There may be more “other” devices in “my” network these days, and vice versa, but so what? That’s not an argument for the disappearing perimeter, per se. It’s an argument for more defense in addition to the perimeter.

increasingly, information will flow between business organizations over shared and third-party networks, so that ultimately the only reliable security strategy is to protect the information itself, rather than the network and the rest of the IT infrastructure

This is true in a narrow scope, but again, there is still a line that can be drawn between the aforementioned “our network” and the “everything else.” This is obvious when speaking about what you own and what you don’t own. You can own the lines and cables and gear up to the demarcation for your ISP, at which point the ISP controls the rest. Has this changed and I didn’t realize it? Yes, business has to pump data over a third-party (the Internet, duh) and that information should be protected (duh). But that doesn’t imply the perimeter is disappearing. Maybe it is disappearing compared to 25 years ago when information stayed inside buildings.

This statement seems to imply that the only recourse is to protect information. This is great as long as we don’t need to ever use that information. Once we open that book that is usually locked in a safe, someone can read over our shoulder, snatch it from our hands, or spill something on it. This is not reality.

The Jericho Forum says this is the trend of de-perimeterization. No, this is a trend in needing defense in depth (depth as in layers or even depth as in deeper inspection at the perimeters). Sadly, defense in depth is a common phrase, and I think their reason for using a “new” term is entirely PR and marketing and to get noticed. Well, they have! 🙂

So let’s just assume they still have a valid point, and there is a need. I’ll buy that because I think that is true, and I really want to give them the benefit of the doubt. Next, I will take a look at their de-perimeterization solutions, also available on their front page.

jericho 1 – de-perimeterization and the jericho forum commandments
jericho 2 – the jericho forum and the de-perimeterization solution
jericho 3 – the first three commandments: the fundamentals
jericho 4 – commandments 4 – 8
jericho 5 – commandments 9-11
jericho 6 – my conclusions

In response to a United Press International report that China has amassed a botnet of 750,000 computers located in the US, the US has mandated a 2-year timeline to force all Internet Service Providers (ISPs) and customers of those ISPs to run government-sponsored botnet-like programs on their computers. All US computers could then be called into service in the event the US finds itself in a cyber war, or needs to protects its cyber interest by launching distributed denial-of-service (DDoS) pre-emptive strikes against its enemies.

A former senior U.S. information security official says there are nearly three-quarter million personal computers in the United States taken over by Chinese hackers.

An unconfirmed US senator has denounced this situation as unacceptable and requires immediate action by the US military and the Department of Homeland Security.

US officials hope that by mandating installed software on US citizen-owned computers, they can call up these forces when needed to form the largest and most powerful botnet in the world, and reclaim dominance of cyberspace. These measures were rushed through Congress and the Senate and have been approved for immediate action.

An anonymous DHS official enthusiastically commented, “Some systems may be put to work cracking password hashes pilfered from enemy systems, while others may scan the Internet for vulnerable enemy systems, and even others can actively be used to attack other systems in the world. Basically, when needed, we could take control of the system in the background, unbeknownst to the user.”

He also added, in concern for ISP cooperation, “ISPs will be forced to require their customers to install our software. They risk losing rights to lines and bandwidth, let alone government penalties, should they not comply.”

This software in question is nearing completion, and the software development firm, still a highly secretive organization close to Silicon Valley with ties to Washington, DC, will run in the background of Windows and Mac systems, with Linux versions planned for the near future. It has been rumored this organization has been working closely with specialists from the Secret Service and NSA.

The Frontier for Internet Safety is heavily opposing these new revelations from the US government, but so far has had little to officially say until they can view the software. They have also suddenly become the victim of a currently ongoing DDoS, so their site may not be available at this time. The source of the attack is still unknown.

DarkReading has a nice article about war walking near the White House and other DC governmental hubs. This certainly takse a level of moxie to even attempt, as I’m not sure I would even try that.

A few points to pull out. I like the mention of EV-DO and would love to see more security measures and exposures on this. I wonder if there is a way to jam EV-DO signals within your area, but not disrupt normal cell phone technology, for instance on a corporate campus. I like the mention that people (even consultants whom you think should know better) piggy-back on any sort of open wireless network they can get to, even if it discloses sensitive information. And a nice quote:

“Later, Rushing shows me how easy it is for a phisher to duplicate one of these internal ‘guest’ log-in screens and grab all the traffic from an unsuspecting client. ‘I’m surprised we don’t see more of that.'”

I’m surprised we don’t see more of this either. I think this is simply a bit more difficult for newbies to do, whereas hacking something like WEP has tons of tutorials which can pay off if the newbie is lucky. I like that these topics come up, because while we have this dull buzz in the background about wireless insecurities, it still is nothing more than a dull buzz. A dangerous dull buzz.

Sadly, this article ends on an off note with the following quote:

“‘Kids are adding to WIGLE all the time — it’s one of the ways you can look cool,’ Rushing says. ‘The more APs you’ve mapped, the cooler you are.'”

If you want to look ignorant and rather retarded, throw a lashout to some useful service and make sure to mention the “kids.” Ugh, this was not necessary to an otherwise good article, and really left me thinking that Rushing is just talking out of his ass here.

Read at least the first few paragraphs of this post on 0x000000.com on how security is useless (wish I could remember who maintains that site, since their name isn’t apparent). If we’re into security or even have a smidgeon of security consciousness in our IT worlds, we’ve been there. In fact, I think we all need to hit this low point in the rollercoaster of life regularly. Really, that’s the point of what we do, right?

Every time I feel this way about security, I am reminded that skilled attackers are still rare and that security does not have to absolutely protect against them. We need to accept that and be happy with that if we’re to continue as an industry or even in our happy lives.

I like to think of security like herding cars, holding sand, or visualizing wind. These are all difficult, if not impossible tasks to do perfectly. That doesn’t mean we do nothing. Security is not black and white, perfect or useless; to believe so means a belief in a silver bullet to achieving a perfect security state. (Think about it for a while and what implications there are which follow certain beliefs.)