I sit here, high above my Brooklyn city below. My view is west, blotted by Brooklyn Heights, down to Buttermilk Channel, up to the East River, across to New Jersey. My view is distance and beautiful. It is away. My view is a perfect analogy of my consciousness. Distance, away. Ignorant. Call this the sub-ego, a portion of the self whose aim to to protect the self by ignorance.
I once recalled the difficulty of asking a friend to lend me $20. I felt a heavy obligation to pay it back. It took a week, where I saved a bit each day. The stress of this was an emotional stir. At this time in my life, that $20 was a large amount to me. It supported me. It was nourishment. Today, $20 has the same meaning to me as $100. They are peers in my mind. This is not me being a braggart. Perhaps, it is more of a confession of how far away I have gotten from my roots.
The sub-ego, or whatever it should be called, drove me to seek out what I did not have or did not want. I didn't dislike being poor, because it was what I knew. And no one could have considered me a pauper, for I wasn't destitute. But as I reaped the fruits of my experience, fertilized by the many in my society, I became ignorant of who I was. I forgot the meaning of $20.
It's amazing what this apathy, grown from ignorance, does to the self. From my view, I can see the tops of buildings, the iconic precipices jutting out of the jungle of Manhattan. Yet, I cannot see the trees below. Nor can I see the courage of those willing to camp out in these trees, waving their fists against what they deem is wrong with society. I cannot hear them, for indifference deafens the ears. I cannot feel them, because I am comfortably numb.
Sunday, October 16, 2011
Monday, September 05, 2011
Time Sharing My Time
So I'm trying something out today, on this wonderful Labor Day. I find I start a lot of small to medium projects that get going, but then die. I could create a list, though it would just make me sad. I find I keep on going on a project when I keep on accumulating small *wins*. That could be added functionality to a program, seeing the accomplishment in action, or getting positive feedback from others. Yes, my ego needs a lot of care and uptake and my mind loves the dopamine release on receiving a reward. Whatever, gotta work with the machine I got :-)
So, today, I tried time sharing my projects. I started a 45 minute timer, and walked down a list of projects. Each got 45 minutes, then whatever amount of break in between. It's a holiday so the breaks are a reward into themselves. If I was billing or charging to a company project, I'd probably care more (or not ; -)
Well, it seemed to work out so far. I went from assessing some technology, documenting changes (locally) to attack surface wording for an OWASP project, playing with puppet, and now onto some node.js stuff. That variability helps keep me motivated to do more, snack bites at a time. Even if I got steam, I was happy to start. It was kinda like a cliffhanger. Otherwise, I run the risk of going through a manic-obsessive cycle, where I spend 10 hrs doing one task and then don't touch it for a month.
Time will tell if this little process change helps or hinders. But at least on today's holiday, it helps.
Cheers!
So, today, I tried time sharing my projects. I started a 45 minute timer, and walked down a list of projects. Each got 45 minutes, then whatever amount of break in between. It's a holiday so the breaks are a reward into themselves. If I was billing or charging to a company project, I'd probably care more (or not ; -)
Well, it seemed to work out so far. I went from assessing some technology, documenting changes (locally) to attack surface wording for an OWASP project, playing with puppet, and now onto some node.js stuff. That variability helps keep me motivated to do more, snack bites at a time. Even if I got steam, I was happy to start. It was kinda like a cliffhanger. Otherwise, I run the risk of going through a manic-obsessive cycle, where I spend 10 hrs doing one task and then don't touch it for a month.
Time will tell if this little process change helps or hinders. But at least on today's holiday, it helps.
Cheers!
Thursday, July 07, 2011
Measuring An Application's Attack Surface To Measure Consultancies
The ability to as-automatically-as-possible measure an application's surface area / attack surface should be one of the Millennium Prizes. Sadly, they only care about stupid problems such as does P=NP? Of course it does! For application security, this measurement can provide a comparable metric to the application's potential for security issues. Enough on that. I'm not trying to prove out an app's security this time. I want navel-gaze at our wonderful infosec industry.
An interesting byproduct of adequately measuring an app's attack surface, and to use the CMU researchers' verbiage, channels, methods, data and entry points, is that it provides a lot of scoping information on the application. No, no, no, I don't care about using this to guess the right amount of hours to assess an app (although that's possible). Rather, imagine if the client stated to a consultancy the following.
Client: "Hello Consultancy."
Consultancy: "Hello Client."
Client: "We have App XZY that has one channel of concern, with 15 direct entry points (methods that receive environment data)."
Consultancy: "Sounds good!"
[... time passes, consultancy is assessing application ...]
Consultancy: "Hello again Client!"
Client: "Hello again Consultancy!"
Consultancy: "We analyzed each of the 15 entry points and found the following. On average, each entry point used 25 different portions of the data, for a total of 375 data fragments [my word] consumed by the entry points. Out of these 375 data fragments, 200 were used in a conditional statement somehow, 100 were persisted by the application and 75 were reflected back to the user. We then examined each of those data fragments for appropriate validation and contextual encoding, if necessary. Blah blah blah XSS blah blah blah SQLi blah blah blah."
Client: "Wow! That's a lot of numbers that don't mean anything to me!!!"
Consultancy: "Oh, hold the boat there Mr. Client! You can start to use these numbers to measure the efficacy of other consultancies and tools. Of course that new Sprint you're about to do on your codebase will screw up all of these numbers. But, you can pay me to measure this again!"
Client: "Oh, I see. So, I can measure your work against another consultancy's work and see how closely you all got."
Consultancy: "Yeppers. So, when we leave here, you'll have at least an idea of what we did. You should then get someone else in the door to do an assessment on this app and see what they come up with. The sooner, the better, since you're pushing new code to QA this Friday."
So, yeah, measuring an app's attack surface down to how many data fragments exist (think HTTP parameters or header content for a web app) and how they're used can become a relative metric on the efficacy of consultancies, in addition to the many other benefits it provides. But, as I snarkily allude to above, it's fraught with issues, especially on the "freshness" of those measurements. I so wish magical tools did this. Our industry, and our client's appsec, would only benefit from it.
An interesting byproduct of adequately measuring an app's attack surface, and to use the CMU researchers' verbiage, channels, methods, data and entry points, is that it provides a lot of scoping information on the application. No, no, no, I don't care about using this to guess the right amount of hours to assess an app (although that's possible). Rather, imagine if the client stated to a consultancy the following.
Client: "Hello Consultancy."
Consultancy: "Hello Client."
Client: "We have App XZY that has one channel of concern, with 15 direct entry points (methods that receive environment data)."
Consultancy: "Sounds good!"
[... time passes, consultancy is assessing application ...]
Consultancy: "Hello again Client!"
Client: "Hello again Consultancy!"
Consultancy: "We analyzed each of the 15 entry points and found the following. On average, each entry point used 25 different portions of the data, for a total of 375 data fragments [my word] consumed by the entry points. Out of these 375 data fragments, 200 were used in a conditional statement somehow, 100 were persisted by the application and 75 were reflected back to the user. We then examined each of those data fragments for appropriate validation and contextual encoding, if necessary. Blah blah blah XSS blah blah blah SQLi blah blah blah."
Client: "Wow! That's a lot of numbers that don't mean anything to me!!!"
Consultancy: "Oh, hold the boat there Mr. Client! You can start to use these numbers to measure the efficacy of other consultancies and tools. Of course that new Sprint you're about to do on your codebase will screw up all of these numbers. But, you can pay me to measure this again!"
Client: "Oh, I see. So, I can measure your work against another consultancy's work and see how closely you all got."
Consultancy: "Yeppers. So, when we leave here, you'll have at least an idea of what we did. You should then get someone else in the door to do an assessment on this app and see what they come up with. The sooner, the better, since you're pushing new code to QA this Friday."
So, yeah, measuring an app's attack surface down to how many data fragments exist (think HTTP parameters or header content for a web app) and how they're used can become a relative metric on the efficacy of consultancies, in addition to the many other benefits it provides. But, as I snarkily allude to above, it's fraught with issues, especially on the "freshness" of those measurements. I so wish magical tools did this. Our industry, and our client's appsec, would only benefit from it.
Friday, March 18, 2011
RSA SecurID Hack, Should I Care?
Twitter was abuzz yesterday and today on the RSA hack. From what I could infer, worst case, the SecurID seed files may have been disclosed in a hack. A quick primer on SecurID is needed to see why this is and isn't an issue.
Token: hardware or software device that displays a token code
Token code: pseudo-random numbers displayed on a RSA token. Can change at different frequencies (30 seconds, 1 minute, etc.)
PIN: user's secret code. Can be numeric or alphanumeric, depending upon configuration.
Passcode: PIN+tokencode
RSA SecurID uses soft and hard tokens. I'll focus on the hard tokens for this. The tokens as I understand them are PRNG. Each token has a random seed to start its PRNG. The date and time the token was started with the seed, along with the seed itself, and the token's serial number, are sent to the customer. The customer then loads this seed file into the Primary SecurID server at the customer's premise. The Primary then can guess the current tokencode displayed on the token by inputting this seed into the PRNG. Clock-skew aside, the code computed by the Primary should be the code displayed on the token.
As the customer adds users to the system, the customer associates a token to some user ID. This association should never be known outside of the Primary, secondaries, and backups. Usually front-end authenticators communicate to the Primary, via RADIUS, RSA's own proprietary protocol, or other supported methods. So, assuming an attacker has obtained the seed files, token serial numbers, and the organization that received the seed files, they'll still need to know the user ID association, the user's PIN, and the relative clock skew of the token.
The RSA hack though only buys the attacker the first part of the equation (seed, token, date). The attacker would still need to perform a targeted attack against a user / org to obtain the token <=> user mapping AND the user's PIN. The Primary has mitigating controls to lock out a user after some amount of failed login attempts. But, let's hand-wave and say the attacker has somehow obtained the token <=> user account mapping and the user's PIN, which could be the user's domain password in some setups. They still need to generate the tokencode on the token.
Getting back to clock skew, since physical tokens are physical, its clock will skew over time. The Primary stores this skew and allows a range. The more the token is used, the better the Primary will know its skew. If the token is too far out of skew, the Primary will log an event and require the to user enter the subsequent token code. If the token continues go to out of skew, the Primary will disallow its use and require the user to obtain a new token. An attacker starting a blind attack will not know the token's relative skew. So, even if this is a targeted attack against an individual, where the attacker knows the seed, token serial number, user ID, and user's PIN, there's still even a chance that the attacker will not be able to authenticate because of the token's clock skew will be too far off.
With all of this, there is some worry. If you're in a small organization with say 20 people, it'll be easier for a knowledgeable attacker to associate some random token to some user account. RSA should also do the right thing and allow organizations to replace their tokens if the organizations deem it necessary, free of charge. A large organization will probably not do this, though. It's costly to do mass upgrades of tokens. For example, each token has an expiration date of usually 2-3 years. After this time, an organization will have to phase in a token replacement process. Support calls go up. People get locked out. It's a pain. But, if you're a small shop, it's easier to manage this. And, if you're a small shop, you're at a higher risk.
In the end, it's about your organization's relative risk. I just don't see a big story here.
(Updated 11:37 EDT: noticed I wrote PIN/passcode before. This was incorrect. Changed to PIN.)
Token: hardware or software device that displays a token code
Token code: pseudo-random numbers displayed on a RSA token. Can change at different frequencies (30 seconds, 1 minute, etc.)
PIN: user's secret code. Can be numeric or alphanumeric, depending upon configuration.
Passcode: PIN+tokencode
RSA SecurID uses soft and hard tokens. I'll focus on the hard tokens for this. The tokens as I understand them are PRNG. Each token has a random seed to start its PRNG. The date and time the token was started with the seed, along with the seed itself, and the token's serial number, are sent to the customer. The customer then loads this seed file into the Primary SecurID server at the customer's premise. The Primary then can guess the current tokencode displayed on the token by inputting this seed into the PRNG. Clock-skew aside, the code computed by the Primary should be the code displayed on the token.
As the customer adds users to the system, the customer associates a token to some user ID. This association should never be known outside of the Primary, secondaries, and backups. Usually front-end authenticators communicate to the Primary, via RADIUS, RSA's own proprietary protocol, or other supported methods. So, assuming an attacker has obtained the seed files, token serial numbers, and the organization that received the seed files, they'll still need to know the user ID association, the user's PIN, and the relative clock skew of the token.
The RSA hack though only buys the attacker the first part of the equation (seed, token, date). The attacker would still need to perform a targeted attack against a user / org to obtain the token <=> user mapping AND the user's PIN. The Primary has mitigating controls to lock out a user after some amount of failed login attempts. But, let's hand-wave and say the attacker has somehow obtained the token <=> user account mapping and the user's PIN, which could be the user's domain password in some setups. They still need to generate the tokencode on the token.
Getting back to clock skew, since physical tokens are physical, its clock will skew over time. The Primary stores this skew and allows a range. The more the token is used, the better the Primary will know its skew. If the token is too far out of skew, the Primary will log an event and require the to user enter the subsequent token code. If the token continues go to out of skew, the Primary will disallow its use and require the user to obtain a new token. An attacker starting a blind attack will not know the token's relative skew. So, even if this is a targeted attack against an individual, where the attacker knows the seed, token serial number, user ID, and user's PIN, there's still even a chance that the attacker will not be able to authenticate because of the token's clock skew will be too far off.
With all of this, there is some worry. If you're in a small organization with say 20 people, it'll be easier for a knowledgeable attacker to associate some random token to some user account. RSA should also do the right thing and allow organizations to replace their tokens if the organizations deem it necessary, free of charge. A large organization will probably not do this, though. It's costly to do mass upgrades of tokens. For example, each token has an expiration date of usually 2-3 years. After this time, an organization will have to phase in a token replacement process. Support calls go up. People get locked out. It's a pain. But, if you're a small shop, it's easier to manage this. And, if you're a small shop, you're at a higher risk.
In the end, it's about your organization's relative risk. I just don't see a big story here.
(Updated 11:37 EDT: noticed I wrote PIN/passcode before. This was incorrect. Changed to PIN.)
Sunday, February 27, 2011
Dropping the Race Card
I recently watched again the movie Malcolm X. There's a good scene when Malcolm X and Baines are going through an English dictionary and comparing connotations between words starting or containing white versus black. The movie posits English words containing white often have some type of positive connotation whilst words containing black have negative connotations. Does infosec and IT in general carry over these connotations? To me...
Yeah, it seems to me. This isn't a poke at Infosec by me since I haven't perceived overt racism by the people I follow or with whom I associate. And also to be fair, these words weren't introduced by Infosec. They were borrowed from some other context.
However, being ethnically a Euro-mutt, my perceptions are more than likely biased. Words do carry meaning, implied or not. I don't see this as a political-correctness issue. Rather, our words frame our mindset. Kinda like a same-origin policy breach. If I connote a feeling with a particular word, it will by nature, leak out into different realms of my being.
Now, having grown up and lived in Minnesota (you betcha!) most of my life, I do not connote the word white with 100% positive emotions; white snow definitely solicits negative feelings in me :-) But I do see the connotations and don't want to perpetuate them. Sadly, the alternatives aren't full of awesome-sauce:
- Black-box versus white-box testing: white-box is more open, transparent, easier to test
- Blacklists versus white lists: blacklists are bad, mmmkay
- Black hats versus white hats: I'm apathetic to either but those evil blackhat scofflaws! ;-)
- ...
Yeah, it seems to me. This isn't a poke at Infosec by me since I haven't perceived overt racism by the people I follow or with whom I associate. And also to be fair, these words weren't introduced by Infosec. They were borrowed from some other context.
However, being ethnically a Euro-mutt, my perceptions are more than likely biased. Words do carry meaning, implied or not. I don't see this as a political-correctness issue. Rather, our words frame our mindset. Kinda like a same-origin policy breach. If I connote a feeling with a particular word, it will by nature, leak out into different realms of my being.
Now, having grown up and lived in Minnesota (you betcha!) most of my life, I do not connote the word white with 100% positive emotions; white snow definitely solicits negative feelings in me :-) But I do see the connotations and don't want to perpetuate them. Sadly, the alternatives aren't full of awesome-sauce:
- Black hat versus white hat: unauthorized hackers versus authorized hackers? (and hackers carries its own connotations... geez)
- Blacklists versus white-lists: exclusion-only filters versus inclusion-only filters? (7 syllables to replace 2 ain't cool)
- Black-box testing versus white-box testing: zero-knowledge testing versus full-knowledge testing? (not too bad)
Thursday, December 16, 2010
Complexity != Insecurity
Why do organizations often tend to introduce more complexity! Complexity is harmful for security ("KISS" principle)
I saw this tweet this morning and cried again. It was a really long cry. Actually, it was sweat going into my eyes because I'm out of shape and on the elliptical. Pretend they were tears of sadness!
Complexity does not equal insecurity. Complexity is not harmful for security. Heck, complexity is welcomed! Sometimes... And, arguably, sometimes not. Complexity can be needed for security, scalability, and consistency. And brother, I'm gonna preach on why.
Complexity Needed For Security
This is a cheap shot. Tell me, what's more of a complex protocol? HTTP or HTTP over a TLS connection? Think TLS isn't complex? It is. But its complexity and functionality add confidentiality, integrity, and authentication to a connection that doesn't directly offer those features. I won't focus on this one, but think about it.
Complexity Needed for Scalability
Before venturing here, be familiar with Big O notation. At least don't be afraid of O(1), O(N), and O(c^N).
UNIX systems manage passwords via a shadow or master password file. A sysadmin managing a small number of UNIX systems may be inclined to manually make updates to these files via their supported methods. The sysadmin might have to infrequently add or delete accounts, as needed and requested. This is very manageable and scales well to the scenario.
The sysadmin didn't realize his company would explode in growth over the next year. Each week brought on scores and scores of new employees and also the need for more and more servers. Now, instead of managing a couple changes a day over a couple systems, the sysadmin is coping with numerous changes a day, across a growing expanse of systems. Performing this manually is time consuming and also adds inflexibility if the sysadmin needs to quickly disable access.
The sysadmin, being lazy, hooks up to the company's Active Directory instance via LDAP. Now, the sysadmin needs to modify PAM modules (authentication) and name service lookups (authorization) across all of these systems. The sysadmin has effectively increased the complexity of a login from a local lookup to a remote lookup because a procedure that was O(N*M) for a small number of users (N) and a small number of servers (M) is inappropriate for larger sizes of N and M. And the sysadmin gets a security benefit by being able to quickly lock out or disable an account if needed. Is this added complexity more or less insecure?
Complexity Needed for Consistency
Building upon the LDAP example, the sysadmin was managing just CentOS servers. After the growth, the servers were made up of Solaris, CentOS, Redhat and FreeBSD because of business needs. Each of these had different ways to enforce account capabilities and restrictions, such as number of failed attempts before lock out, password complexity and strength, and password expiry days.
Some systems couldn't support what the policy required. Others took time to understand, test, and implement. And others would only work for certain services, say OpenSSH, but not other services, on the server. By having PAM support the authentication and connecting to the LDAP server, the LDAP server can be a single point of control. Or, rather in Big O notation, the sysadmin reduced an O(N) problem to an O(1) problem, with N being the number of servers needing the change. Oh, and I won't mention that the sysadmin will add some more complexity by using STARTTLS with his LDAP implementation to not disclose the hashes being sent across the wire ;-)
Trite Examples, Blah!
Perhaps. The point I'm trying to make is that complexity isn't and shouldn't be viewed as a bastard in the eyes of security. It's not. If the goal of complexity is commensurate with security goals, then it's a win. If complexity changes a process from O(N) to O(1), awesome! If complexity actually adds security at little perceived loss, even better. So, please, if you're gonna beat up on complexity, at least say unnecessary complexity. Because there's a lot of complexity out there that's keeping us secure, and it's a good thing :-)
Sunday, December 05, 2010
Threat Modeling, Attack Trees, Call Graphs, Oh My!
Let's say I'm able to dynamically and statically analyze an application running on some platform. This analysis is so full of awesome that it enumerates every entry and exit point in the application. It enumerates all ways that data is touched, modified or/and returned to the user of the application. It understands authentication and authorization, from the interface down to the underlying operating system.
So what. Really, who cares. There's absolutely no context with this contrived analysis. Let's say that the application above only accesses information deemed public by the application owner. Let's say that the machine has no way to pivot to any other resources: an island. Then what? And why am I wasting time on a post like this that seems pretty obvious?
We have threat modeling, attack trees, call graphs, and everything at our disposal. Automation can get us far, but without subjective context, especially on asset valuation, everything looks the same. I'm all for measurements. We're no where near as an industry in enumerating what applications can do, what they touch, and even how to process all of this information. But even if we were, we would still be silly and mark a remotely exploitable vulnerability that popped root on this application as a "high", whatever that means. Whereas in reality, this asset has such little value that it's not even worth including its system name in a report.
We do not do a good job assessing asset values, however subjective. Yes, there's value for an attacker. At a minimum, can I pivot from this host? Can I now access something I wasn't able to access before? These are valid and should be called out if there's reason to. But, what about the data? Not all assets are equal and we should stop treating them as they are.
So what. Really, who cares. There's absolutely no context with this contrived analysis. Let's say that the application above only accesses information deemed public by the application owner. Let's say that the machine has no way to pivot to any other resources: an island. Then what? And why am I wasting time on a post like this that seems pretty obvious?
We have threat modeling, attack trees, call graphs, and everything at our disposal. Automation can get us far, but without subjective context, especially on asset valuation, everything looks the same. I'm all for measurements. We're no where near as an industry in enumerating what applications can do, what they touch, and even how to process all of this information. But even if we were, we would still be silly and mark a remotely exploitable vulnerability that popped root on this application as a "high", whatever that means. Whereas in reality, this asset has such little value that it's not even worth including its system name in a report.
We do not do a good job assessing asset values, however subjective. Yes, there's value for an attacker. At a minimum, can I pivot from this host? Can I now access something I wasn't able to access before? These are valid and should be called out if there's reason to. But, what about the data? Not all assets are equal and we should stop treating them as they are.
Subscribe to:
Posts (Atom)
