A little while ago I started doing something that I've toyed with doing off and on: I started an Avon business. Yup. I'm a girl.
I've been a little embarrassed about it, I guess, probably because I'm underemployed and I don't want to come off as desperate. I'm not desperate, and if I were, I probably wouldn't be starting an Avon business, because you really need to put money into it (as with any business) before you can see any kind of profit.
I also don't want to appear to prey on people. "You're my friennnnnnd...buy from meeeeeeee" just isn't my style. I've mentioned it to people, and I did sort of bully my mom into switching to me for her representative, but my feeling is that if and when people buy cosmetics and fragrances and the other stuff Avon sells, it should be because they want to, not because they feel sorry for their friend. I don't mind being (gently) pushy about asking people to buy it from me as opposed to someone else, but to buy it in the first place...no.
That said, one of the reasons why I started this when I had some free time but wasn't yet strapped for cash (both from being between infosec positions) is that I wanted to buy some of the products myself and take advantage of special representative-only offers and samples so that I could say with authority, "Hey, I like this product and I think you would too," or just respond knowledgeably when people asked me about the product line. For instance, Avon heavily touts their Lotus Shield anti-frizz product, so I ganked a sample packet and it's currently sitting in my hair. I have a very sensitive scalp and very fine, wavy hair, so I should soon know if the product irritates my scalp or makes my hair feel icky, and I'll know how I want to approach selling it. This is something Avon encourages, i.e. getting to know their products, and since I've always liked Avon, they don't need to ask twice.
The question remains: Why am I, a network security analyst, selling Avon? The reasons are threefold:
1. I love makeup. I know, I know, as a feminist I am supposed to feel that wearing makeup is succumbing to oppression or something like that. But I don't. I don't spend a lot of money on makeup or hair or clothing, but I do enjoy buying and using it, a lot.
2. I love showing other people how to do stuff. Showing people how to "do infosec", in whatever way, is one of my favorite things about being in the field, and why I'm so good at whatever job I may hold. I'm hoping that it's also going to be a big part of my Avon business. My favorite part is going to be showing other people how to do stuff and helping them find the best products for their particular needs, just as it is in infosec.
3. I want to know if I can do it, and by "do it" I mean sell something. I've always felt like a total failure at sales of any kind. Believe it or not, I'm painfully shy and I have a hard time approaching people in a selling context. So I'm hoping that selling something that I happen to love myself, when it's not a make-it-or-break-it for me, will make me more confident about the concept of selling in general. I'm not expecting this to be my livelihood; I just want to put myself outside my comfort zone and see what happens.
So ding dong! Avon calling!
Thursday, March 31, 2011
Tuesday, March 29, 2011
data loss redux: thinking organically
A little while ago I wrote about DLP, or Data Loss Prevention, and how the term is something of a red herring because, in reality, everything we do is about preventing data loss; ergo, the concept can't be neatly productized. I still feel that way.
However, a few days after I posted it, I was contacted by a fellow named Pablo Osinaga, who has co-founded a startup called Kormox. He wanted me to see his company's DLP solution, profiled by SC Magazine.
After reading SC's blurb on the subject, I was quite intrigued, and arranged a web/phone meeting with Mr. Osinaga. For a little over an hour, we discussed Kormox and the concept of DLP.
As I said, DLP is a very difficult concept to productize. Everyone needs to prevent the loss or leakage of data, but everyone -- every enterprise, every business, every organization, even every person -- has different data and different types of data that they need to protect. Some organizations are concerned with mobile data; some are concerned with file shares; some are concerned with PII; and so on. No one vendor -- no one product -- has a fully comprehensive DLP solution because what DLP means is so dependent on each organization's mission and needs, which not only differs among organizations but can be subject to change within an organization over time.
One of the first things that Mr. Osinaga mentioned, in presenting his company's solution, was that enterprises have become more organic and less structured. I could not agree more. I have worked for many different security solutions vendors, and I hear over and over about the "special snowflake syndrome", how every organization thinks they are "different" in some way, but they are really all the same. The trend, with every security vendor I've worked with, is to pigeonhole potential and existing customers, to basically tell them that they can't have what they say they want, to fit them to the solution that the vendor has, in their infinite wisdom, envisioned and created. Yet as time goes on, and as Mr. Osinaga noted, enterprise structure is becoming more fluid, less definable, and less able to be pigeonholed.
Kormox's solution starts with data classification. It's so simple, and so logical. Of course you have to classify your data. But it's not enough to say "I have to protect medical records" or "I have to protect credit card numbers". In the DLP-productization game, vendors talk about what kind of data you want to protect, and then they talk about how they're going to protect it, but they don't really cover the territory of what, exactly, your data means to the people who are using it. That's your problem.
And that's how Kormox differentiates itself from the crowd: data classification is a major step, and it involves finding out not only what the data is (as opposed to merely what kind of data), but the flow of the data: where it is, who is using it, how they use it, where it's going, where it's been, and so on. All this is part of the classification, and it brings DLP back to the true "asset management" model of Information Security, where the asset is the data itself, not the (often fungible) hardware on which it rests.
After the data has been classified, the product allows the asset owners to implement controls in a similarly organic fashion. In essence, it takes the organization from the situation of "I know I need to protect our data" to "I know where and what all our data is, how it's used, and what controls are on it" -- something that no other DLP solution does.
I'm not laboring under an illusion that this product is perfect; no product could be. But I do think that Kormox is going in a necessary direction with their concept of data flow as a part of classification. At the moment it's a bit clunky looking, but from what I saw in our meeting, it is definitely worth a look.
I'd like to note that I am in no way compensated for writing about Kormox; I'm writing about it because Mr. Osinaga contacted me as a result of my last DLP article, and so I thought it was only fair to talk about what I found out in our meeting.
However, a few days after I posted it, I was contacted by a fellow named Pablo Osinaga, who has co-founded a startup called Kormox. He wanted me to see his company's DLP solution, profiled by SC Magazine.
After reading SC's blurb on the subject, I was quite intrigued, and arranged a web/phone meeting with Mr. Osinaga. For a little over an hour, we discussed Kormox and the concept of DLP.
As I said, DLP is a very difficult concept to productize. Everyone needs to prevent the loss or leakage of data, but everyone -- every enterprise, every business, every organization, even every person -- has different data and different types of data that they need to protect. Some organizations are concerned with mobile data; some are concerned with file shares; some are concerned with PII; and so on. No one vendor -- no one product -- has a fully comprehensive DLP solution because what DLP means is so dependent on each organization's mission and needs, which not only differs among organizations but can be subject to change within an organization over time.
One of the first things that Mr. Osinaga mentioned, in presenting his company's solution, was that enterprises have become more organic and less structured. I could not agree more. I have worked for many different security solutions vendors, and I hear over and over about the "special snowflake syndrome", how every organization thinks they are "different" in some way, but they are really all the same. The trend, with every security vendor I've worked with, is to pigeonhole potential and existing customers, to basically tell them that they can't have what they say they want, to fit them to the solution that the vendor has, in their infinite wisdom, envisioned and created. Yet as time goes on, and as Mr. Osinaga noted, enterprise structure is becoming more fluid, less definable, and less able to be pigeonholed.
Kormox's solution starts with data classification. It's so simple, and so logical. Of course you have to classify your data. But it's not enough to say "I have to protect medical records" or "I have to protect credit card numbers". In the DLP-productization game, vendors talk about what kind of data you want to protect, and then they talk about how they're going to protect it, but they don't really cover the territory of what, exactly, your data means to the people who are using it. That's your problem.
And that's how Kormox differentiates itself from the crowd: data classification is a major step, and it involves finding out not only what the data is (as opposed to merely what kind of data), but the flow of the data: where it is, who is using it, how they use it, where it's going, where it's been, and so on. All this is part of the classification, and it brings DLP back to the true "asset management" model of Information Security, where the asset is the data itself, not the (often fungible) hardware on which it rests.
After the data has been classified, the product allows the asset owners to implement controls in a similarly organic fashion. In essence, it takes the organization from the situation of "I know I need to protect our data" to "I know where and what all our data is, how it's used, and what controls are on it" -- something that no other DLP solution does.
I'm not laboring under an illusion that this product is perfect; no product could be. But I do think that Kormox is going in a necessary direction with their concept of data flow as a part of classification. At the moment it's a bit clunky looking, but from what I saw in our meeting, it is definitely worth a look.
I'd like to note that I am in no way compensated for writing about Kormox; I'm writing about it because Mr. Osinaga contacted me as a result of my last DLP article, and so I thought it was only fair to talk about what I found out in our meeting.
Friday, March 18, 2011
data loss prevention: a red herring
A few years ago, the acronym DLP, which stands for Data Loss (or Leakage) Prevention, hit the security market. Every enterprise was crazy for it, every vendor touted it, and everybody had a different idea of what, exactly, it was.
Half a decade has passed and we still don't know. The problem is that DLP is a misleading term, because preventing data loss is the key reason for information security in the first place. If you think about it, every component of your enterprise's security solution, from policy to compliance reports, is in place to prevent your data from being lost or leaked.
There is no panacea for the problem of potential data loss, no matter what your vendor of choice might tell you. The smartest vendors don't even try to claim such a thing. Because nobody can agree on what, exactly, DLP is, nobody has a complete solution. However, the industry in general does agree on a few key concepts:
- A product that can recognize credit card / SSN / other identifying data both at rest and in motion and (better) control the transmission of such data is a necessary part of your security solution, if you deal with such data
- A product that can tag certain types of files and control the transmission (in whole or in part, encrypted or not) of those files is key
- A product that can recognize certain types of removable storage device being attached and/or written to and IMMEDIATELY control this activity is important
- If your business employs "mobile warriors" and you do not implement some sort of whole disk and file encryption, your data is at risk
- If your employees use mobile phones for business purposes then you should have some control over what type of data they can access on those devices
These are just a few of the concepts behind DLP, and those concepts keep changing as new risks are discovered. Adding to the complexity is the fact that some issues are going to apply to some enterprises, whereas other issues will be unimportant. For instance, the DoD never, ever transmits SSNs in the clear. However, many private sector businesses transmit SSNs in the clear as a matter of course (although they shouldn't). Ergo, when the DoD talks about data leakage, they are most often concerned with SSNs and other types of personally identifying information (referred to as PII), but protecting credit card information is not so much a concern. The private sector, on the other hand, is much more occupied with protecting credit card information but not so much (say) SSNs, driver license numbers, and other types of PII. Ergo, the part of the DLP solution that identifies certain types of data at rest and in motion needs to be flexible and customizable to be useful for the environment it's being used in.
Whole disk and file encryption is probably the easiest piece of the DLP pie to choose and to implement. In fact, you can get your whole disk encryption from one source and your file encryption from another, and as long as they don't fight with each other you're fine (as long as you remember that nothing is 100% foolproof, that is). But after that, it gets more complex, and vendors only make it worse when they try to convince you that their solution does everything you need for DLP. Well, no, it doesn't.
A smart executive will realize that DLP is not a single concept, and certainly not a single product; rather, it's a method. The first thing to do is to revisit your security policy. If you do not have a section detailing the specific types of data that you need to protect from loss/leakage and some (probably non-vendor-specific) methods for doing so, then it is time for a rewrite. [Note: you should be revisiting and perhaps editing your security policy on at least a quarterly basis anyway.] Sit down with your fellow executives and brainstorm your data pitfalls, and then do the courtship dance with vendors who claim to have solutions to these pitfalls. Again, do not fall into the trap of the One True Solution. It doesn't exist.
As you work on your DLP method, you will see that many of your current solutions and/or their vendors already work towards securing your data...of course, because that, as I said, is the entire point of infosec. For instance, your vulnerability scanner already scans for removable storage devices (both currently inserted and having been inserted at any time). That's great, but it's asynchronous. Does the vendor have a real-time solution (agent or sniffer based) that does the same thing? You already have auditing in place to determine if a file's been touched. How about if it's been excerpted and transmitted without being edited? And so on. If your current vendors have addons that can fit your newly-perceived needs, then that can perhaps save you money and implementation time.
One big problem with potential data leakage is that many businesses, to save money, don't issue their employees mobile phones but rather reimburse the employee if his or her existing phone is used for business purposes. However, in many cases, "business purposes" doesn't mean just calls; if an employee is using a smartphone, he or she is probably also downloading and responding to email and possibly also VPN'ing into the network and accessing corporate resources. If you're not virus scanning and otherwise protecting his phone in the event of theft and other compromise, then all the time and expense that you've gone to in implementing disk and file encryption on his laptop is pretty much useless.
All of this is a lot to think about. The good news, especially if you are a smaller business, is that you don't have to think about it and implement it all at once. This is why you should be always spiralling back to your security policy in order to revist your business's current needs. Each time, you can tighten up your data security a little more.
Half a decade has passed and we still don't know. The problem is that DLP is a misleading term, because preventing data loss is the key reason for information security in the first place. If you think about it, every component of your enterprise's security solution, from policy to compliance reports, is in place to prevent your data from being lost or leaked.
There is no panacea for the problem of potential data loss, no matter what your vendor of choice might tell you. The smartest vendors don't even try to claim such a thing. Because nobody can agree on what, exactly, DLP is, nobody has a complete solution. However, the industry in general does agree on a few key concepts:
- A product that can recognize credit card / SSN / other identifying data both at rest and in motion and (better) control the transmission of such data is a necessary part of your security solution, if you deal with such data
- A product that can tag certain types of files and control the transmission (in whole or in part, encrypted or not) of those files is key
- A product that can recognize certain types of removable storage device being attached and/or written to and IMMEDIATELY control this activity is important
- If your business employs "mobile warriors" and you do not implement some sort of whole disk and file encryption, your data is at risk
- If your employees use mobile phones for business purposes then you should have some control over what type of data they can access on those devices
These are just a few of the concepts behind DLP, and those concepts keep changing as new risks are discovered. Adding to the complexity is the fact that some issues are going to apply to some enterprises, whereas other issues will be unimportant. For instance, the DoD never, ever transmits SSNs in the clear. However, many private sector businesses transmit SSNs in the clear as a matter of course (although they shouldn't). Ergo, when the DoD talks about data leakage, they are most often concerned with SSNs and other types of personally identifying information (referred to as PII), but protecting credit card information is not so much a concern. The private sector, on the other hand, is much more occupied with protecting credit card information but not so much (say) SSNs, driver license numbers, and other types of PII. Ergo, the part of the DLP solution that identifies certain types of data at rest and in motion needs to be flexible and customizable to be useful for the environment it's being used in.
Whole disk and file encryption is probably the easiest piece of the DLP pie to choose and to implement. In fact, you can get your whole disk encryption from one source and your file encryption from another, and as long as they don't fight with each other you're fine (as long as you remember that nothing is 100% foolproof, that is). But after that, it gets more complex, and vendors only make it worse when they try to convince you that their solution does everything you need for DLP. Well, no, it doesn't.
A smart executive will realize that DLP is not a single concept, and certainly not a single product; rather, it's a method. The first thing to do is to revisit your security policy. If you do not have a section detailing the specific types of data that you need to protect from loss/leakage and some (probably non-vendor-specific) methods for doing so, then it is time for a rewrite. [Note: you should be revisiting and perhaps editing your security policy on at least a quarterly basis anyway.] Sit down with your fellow executives and brainstorm your data pitfalls, and then do the courtship dance with vendors who claim to have solutions to these pitfalls. Again, do not fall into the trap of the One True Solution. It doesn't exist.
As you work on your DLP method, you will see that many of your current solutions and/or their vendors already work towards securing your data...of course, because that, as I said, is the entire point of infosec. For instance, your vulnerability scanner already scans for removable storage devices (both currently inserted and having been inserted at any time). That's great, but it's asynchronous. Does the vendor have a real-time solution (agent or sniffer based) that does the same thing? You already have auditing in place to determine if a file's been touched. How about if it's been excerpted and transmitted without being edited? And so on. If your current vendors have addons that can fit your newly-perceived needs, then that can perhaps save you money and implementation time.
One big problem with potential data leakage is that many businesses, to save money, don't issue their employees mobile phones but rather reimburse the employee if his or her existing phone is used for business purposes. However, in many cases, "business purposes" doesn't mean just calls; if an employee is using a smartphone, he or she is probably also downloading and responding to email and possibly also VPN'ing into the network and accessing corporate resources. If you're not virus scanning and otherwise protecting his phone in the event of theft and other compromise, then all the time and expense that you've gone to in implementing disk and file encryption on his laptop is pretty much useless.
All of this is a lot to think about. The good news, especially if you are a smaller business, is that you don't have to think about it and implement it all at once. This is why you should be always spiralling back to your security policy in order to revist your business's current needs. Each time, you can tighten up your data security a little more.
Saturday, March 12, 2011
the most important infosec component
Also posted in my Securiteam blog.
When I first started working in Information Security, the big "thing" was firewalls. It's probably hard to believe now, but back then, it wasn't simply a question of which firewall to install but rather whether to install one at all. I spoke to a lot of former sysadmins who had been repurposed, willy-nilly, as security engineers. They didn't know much about network security, but they did know that they probably needed to keep "bad stuff" out: hence, the firewall.
These days, if you are in charge of security for an enterprise, you don't ask yourself if you should install a firewall; instead you're trying to figure out what types and how many different kinds of intrustion prevention you can get away with on your budget, along with asset and vulnerability scanners, SIEMs, and on and on. Information security has been productized to the point where it's easy to forget the single most important infosec component in any business, and by that I mean the people who work for and with it.
Smart CEOs these days will say that their most important assets are their employees. That's very warm and fuzzy, but anybody who has been let go from a company for any reason that isn't related directly to job performance will tell you that upper level management cares much more about the bottom line than about the inner workings of their employees' minds. I'm not crazy: a business has to make money, because that is the reason it exists. But businesses also have to realize that employees are, in fact, both assets and liabilties when it comes to that bottom line.
Consider this: every single one of your employees has a life outside his or her job. Mary is a devout Catholic who sings in her church's award-winning choir. Bill plays in a poker league on Thursday nights and weekends. George and his wife Tess, who both work for different departments, sell Amway together. Jeannette saves up her paid time off to travel all over the world. And Jack? That kind of gothy looking guy with the tattoos that you have working in the infosec department, the one who begs you to send him to SANS and Black Hat every year? Well, when you don't, he splits the difference and goes to LayerOne and SchmooCon and DefCon.
You can't control what your employees do in their spare time, nor should you. But if you think that they are not thinking about what they do in their spare time while they are at work, you are wrong, and that is what so many executives don't take into account when they are thinking about their company's security posture. The "rank and file" care about the company's bottom line insofar as it provides them with a paycheck, and most of the time, that is where their caring stops. They do not realize, because it is not part of their job to do so, that what they are thinking or doing at any given point could affect your business. You don't realize it either, and that's a problem, because it IS part of your job to know that.
If your business is subject to government or industry regulation(s), you very likely have a security policy. This policy defines physical and network assets, who has access to them, and some kind of vulnerability management and compliance schedule, at a minimum. You probably think that the "access" part takes care of intentional or unintentional abuse of your non-human assets by your human assets: they can't use the red stapler; they can't access the HR file server; they can't post to Facebook from the company network. Even if you can't stop them, they know from reading the policy that if they are caught doing any of those things, they could be punished, including losing their jobs.
Your employees are smart and innovative: that is why you hired them. They can, or think they can, outwit your automated security components to do what they want to do, and as long as they are also getting their jobs done, no harm no foul, right? Wrong: every minute a human asset spends doing something at work that is against your security policy is a minute of their salary, and, should it end up causing problems that need to be corrected, the salaries of other human assets. This leads in turn to the company's bottom line being adversely affected over time.
You might think that the obvious solution to this problem is to employ tighter controls and install more automated security components in order to get your human assets to adhere to your security policy. However, I am going to go out on a limb and say that your first step, when faced with employee non-adherence, is to revisit the security policy and determine how it can be brought in line, while still remaining in compliance with governement and industry regulations, with the reality of what is going on with your employees' lives.
Your employees fail to comply with your security policy, for the most part, not because they don't care but because they don't understand how it affects them. Given how smart they are (right?), if they don't understand this, it is because they've never had it explained to them in a way that they can relate to. As an executive of the company, this is your responsibility: to show your employees how they directly affect the amount of money in their paychecks, and to work with them to make the company, and they themselves, earn more rather than stealing from the bottom line.
Alice likes to post to Facebook on company time? Create a company Facebook page and put Alice and her posty friends in charge of it. Mary is spending too much time on choir-related activities at work? See if you can work her choir or a subset thereof into company events, to everybody's benefit. You're worried about Jack's possible hackerish activities? Send him as an official company rep to the conferences he already attends, plus the ones he wants to attend, and encourage him to share his own ideas for strengthening the security posture of your enterprise. All these things will cost money up front, but you will find that when your employees feel that they are being listened to and valued for who they are, those upfront costs will bring in more revenue for the company. Ask Google.
There is absolutely no way to completely automate security, because you can't control what is going on in the heads of your employees. But when you truly treat your employees as the assets you say they are, your security posture WILL improve.
When I first started working in Information Security, the big "thing" was firewalls. It's probably hard to believe now, but back then, it wasn't simply a question of which firewall to install but rather whether to install one at all. I spoke to a lot of former sysadmins who had been repurposed, willy-nilly, as security engineers. They didn't know much about network security, but they did know that they probably needed to keep "bad stuff" out: hence, the firewall.
These days, if you are in charge of security for an enterprise, you don't ask yourself if you should install a firewall; instead you're trying to figure out what types and how many different kinds of intrustion prevention you can get away with on your budget, along with asset and vulnerability scanners, SIEMs, and on and on. Information security has been productized to the point where it's easy to forget the single most important infosec component in any business, and by that I mean the people who work for and with it.
Smart CEOs these days will say that their most important assets are their employees. That's very warm and fuzzy, but anybody who has been let go from a company for any reason that isn't related directly to job performance will tell you that upper level management cares much more about the bottom line than about the inner workings of their employees' minds. I'm not crazy: a business has to make money, because that is the reason it exists. But businesses also have to realize that employees are, in fact, both assets and liabilties when it comes to that bottom line.
Consider this: every single one of your employees has a life outside his or her job. Mary is a devout Catholic who sings in her church's award-winning choir. Bill plays in a poker league on Thursday nights and weekends. George and his wife Tess, who both work for different departments, sell Amway together. Jeannette saves up her paid time off to travel all over the world. And Jack? That kind of gothy looking guy with the tattoos that you have working in the infosec department, the one who begs you to send him to SANS and Black Hat every year? Well, when you don't, he splits the difference and goes to LayerOne and SchmooCon and DefCon.
You can't control what your employees do in their spare time, nor should you. But if you think that they are not thinking about what they do in their spare time while they are at work, you are wrong, and that is what so many executives don't take into account when they are thinking about their company's security posture. The "rank and file" care about the company's bottom line insofar as it provides them with a paycheck, and most of the time, that is where their caring stops. They do not realize, because it is not part of their job to do so, that what they are thinking or doing at any given point could affect your business. You don't realize it either, and that's a problem, because it IS part of your job to know that.
If your business is subject to government or industry regulation(s), you very likely have a security policy. This policy defines physical and network assets, who has access to them, and some kind of vulnerability management and compliance schedule, at a minimum. You probably think that the "access" part takes care of intentional or unintentional abuse of your non-human assets by your human assets: they can't use the red stapler; they can't access the HR file server; they can't post to Facebook from the company network. Even if you can't stop them, they know from reading the policy that if they are caught doing any of those things, they could be punished, including losing their jobs.
Your employees are smart and innovative: that is why you hired them. They can, or think they can, outwit your automated security components to do what they want to do, and as long as they are also getting their jobs done, no harm no foul, right? Wrong: every minute a human asset spends doing something at work that is against your security policy is a minute of their salary, and, should it end up causing problems that need to be corrected, the salaries of other human assets. This leads in turn to the company's bottom line being adversely affected over time.
You might think that the obvious solution to this problem is to employ tighter controls and install more automated security components in order to get your human assets to adhere to your security policy. However, I am going to go out on a limb and say that your first step, when faced with employee non-adherence, is to revisit the security policy and determine how it can be brought in line, while still remaining in compliance with governement and industry regulations, with the reality of what is going on with your employees' lives.
Your employees fail to comply with your security policy, for the most part, not because they don't care but because they don't understand how it affects them. Given how smart they are (right?), if they don't understand this, it is because they've never had it explained to them in a way that they can relate to. As an executive of the company, this is your responsibility: to show your employees how they directly affect the amount of money in their paychecks, and to work with them to make the company, and they themselves, earn more rather than stealing from the bottom line.
Alice likes to post to Facebook on company time? Create a company Facebook page and put Alice and her posty friends in charge of it. Mary is spending too much time on choir-related activities at work? See if you can work her choir or a subset thereof into company events, to everybody's benefit. You're worried about Jack's possible hackerish activities? Send him as an official company rep to the conferences he already attends, plus the ones he wants to attend, and encourage him to share his own ideas for strengthening the security posture of your enterprise. All these things will cost money up front, but you will find that when your employees feel that they are being listened to and valued for who they are, those upfront costs will bring in more revenue for the company. Ask Google.
There is absolutely no way to completely automate security, because you can't control what is going on in the heads of your employees. But when you truly treat your employees as the assets you say they are, your security posture WILL improve.
Friday, March 11, 2011
Tuesday, March 8, 2011
don't tell me i can't go there
I'd like to note that this is an opinion piece. That said, it HAS to be an opinion piece because there are no "hard" statistics on the subject that prove a point in any way. There is ONLY anecdotal evidence and conjecture. Ergo, this is MY evidence and conjecture.
I read an article a few days ago that really upset me. The reason that it upset me is that it was written by a woman who, like me, has children and loves them but also has a love and a need to work, to have a career, to not be a stay at home mom. Let me be clear: I don't have anything against stay at home moms. I do have something against people who don't want to work and who use their children as an excuse for staying home, but that's neither here nor there. My point is that I am not the kind of person who can find fulfillment in staying home with her kids, and so I don't choose to do so.
I discovered my career around the time I hit 30. I was very ill prepared for any sort of career, frankly, but I was in the right place at the right time and got hired to do technical support. This wasn't technical support of the "click on My Computer" variety, where you follow a script -- you had to be smart, you had to learn, and you had to think. And I did all these things. I was good at it.
I will bet I'd have been even better at it had I realized how good I was at math in school and pursued it. That said, I'd found my niche and I stayed in tech. I went from that company to an infosec vendor, and I realized I had a passion for Information Security. I learned everything I could.
There's one thing that really got in the way of my career, and it was the fact that I am a girl. Not only am I a girl, but I am a really girly girl. I do not look or act particularly smart. I'm cute and I'm sexy, and neither of those attributes come across well in the world of Information Security. I'm a dancing bear.
At any rate, I recently read this article by a woman who seems a lot like me personality-wise, and what she said is that women are, in general, not good at certain things, such as competition or higher math, and so they shouldn't pursue careers where they would have to be highly competitive or use higher math. And you know, she may be right...but there are plenty of women out there who ARE good at competing and with higher math, but who already have to fight harder than men with similar skills to be hired and to be taken seriously, and this woman's article DOES NOT HELP.
I am one of those girls who, early on, bought into the idea that because I was a girl and because I had big boobs, I was not smart. Seriously, for years I thought I was not very smart, which is hilarious because the evidence that I was, in fact, smart was all around me and I just ignored it because it must have been a fluke. I was good at math, so good at math that I should have been shot into a special class, but they didn't have those when I was a kid, and I actually thought I was BAD at math and stopped taking it the moment I could get away with it. The only thing that I did pursue was languages, and the fact that I was good at languages -- not just speaking or reading, but the technical, formal aspects of languages -- should have alerted somebody, but it didn't. Later on, in college, I astounded some of my professors with how good I was at formal systems, but then I got sick and I had to drop out, and there went any possibility that I'd figure out how good I was.
Five years before I got into tech, I picked up a book on formal systems and idly leafed through it, and then burst into hysterical tears because I FINALLY GOT IT: I realized that I was really, really good at math. I was also pregnant with my second child and had no ability, no opportunity to DO anything about it. Since that time, I have wanted, desperately, to go back to school and do something about it, but for various reasons, and I am not going to recount them all here, I haven't been able to.
Still, I am very good at what I do, much better than I should be considering my lack of formal training. Because I came at tech "sideways", as I like to put it, I very much think outside the box. Most of the time I don't even know there was a box. I'm not saying that I am the best in my field or something like that. But what I am saying is that I am a really good bet to hire, because I love to learn, I love challenges, and I hate being unbusy.
I've never had anyone complain about my technical ability. But I have seen a lot of doors slam in my face nonetheless. I know my personality is way out there and sometimes hard to take, but I will submit that if my personality did not come with big tits and a high voice, it would be much easier to "take".
Because here's the thing: I like being a girl. I love dressing up in outfits that accentuate how cute I am, and wearing makeup. I love to party, particularly if karaoke is involved. I have a lot of interests outside tech, most of which could be considered girly. I am not going to hide or deny that stuff, even though apparently it means that people -- i.e. many men in tech -- can't take me seriously because they can't fit me into a well-defined pigeonhole.
But why should I make it easy for them? Why should I fit into one of their boxes? Why should I accept someone else's definition for what I, as a woman, should be? The answer is that I shouldn't and I won't. If you give me a job to do, I will do that job well, and THAT IS WHAT COUNTS in my field or in any other.
And the last thing I need is another woman telling me that I can't, or shouldn't, try to do what I want to do and am good at because I am a woman.
I read an article a few days ago that really upset me. The reason that it upset me is that it was written by a woman who, like me, has children and loves them but also has a love and a need to work, to have a career, to not be a stay at home mom. Let me be clear: I don't have anything against stay at home moms. I do have something against people who don't want to work and who use their children as an excuse for staying home, but that's neither here nor there. My point is that I am not the kind of person who can find fulfillment in staying home with her kids, and so I don't choose to do so.
I discovered my career around the time I hit 30. I was very ill prepared for any sort of career, frankly, but I was in the right place at the right time and got hired to do technical support. This wasn't technical support of the "click on My Computer" variety, where you follow a script -- you had to be smart, you had to learn, and you had to think. And I did all these things. I was good at it.
I will bet I'd have been even better at it had I realized how good I was at math in school and pursued it. That said, I'd found my niche and I stayed in tech. I went from that company to an infosec vendor, and I realized I had a passion for Information Security. I learned everything I could.
There's one thing that really got in the way of my career, and it was the fact that I am a girl. Not only am I a girl, but I am a really girly girl. I do not look or act particularly smart. I'm cute and I'm sexy, and neither of those attributes come across well in the world of Information Security. I'm a dancing bear.
At any rate, I recently read this article by a woman who seems a lot like me personality-wise, and what she said is that women are, in general, not good at certain things, such as competition or higher math, and so they shouldn't pursue careers where they would have to be highly competitive or use higher math. And you know, she may be right...but there are plenty of women out there who ARE good at competing and with higher math, but who already have to fight harder than men with similar skills to be hired and to be taken seriously, and this woman's article DOES NOT HELP.
I am one of those girls who, early on, bought into the idea that because I was a girl and because I had big boobs, I was not smart. Seriously, for years I thought I was not very smart, which is hilarious because the evidence that I was, in fact, smart was all around me and I just ignored it because it must have been a fluke. I was good at math, so good at math that I should have been shot into a special class, but they didn't have those when I was a kid, and I actually thought I was BAD at math and stopped taking it the moment I could get away with it. The only thing that I did pursue was languages, and the fact that I was good at languages -- not just speaking or reading, but the technical, formal aspects of languages -- should have alerted somebody, but it didn't. Later on, in college, I astounded some of my professors with how good I was at formal systems, but then I got sick and I had to drop out, and there went any possibility that I'd figure out how good I was.
Five years before I got into tech, I picked up a book on formal systems and idly leafed through it, and then burst into hysterical tears because I FINALLY GOT IT: I realized that I was really, really good at math. I was also pregnant with my second child and had no ability, no opportunity to DO anything about it. Since that time, I have wanted, desperately, to go back to school and do something about it, but for various reasons, and I am not going to recount them all here, I haven't been able to.
Still, I am very good at what I do, much better than I should be considering my lack of formal training. Because I came at tech "sideways", as I like to put it, I very much think outside the box. Most of the time I don't even know there was a box. I'm not saying that I am the best in my field or something like that. But what I am saying is that I am a really good bet to hire, because I love to learn, I love challenges, and I hate being unbusy.
I've never had anyone complain about my technical ability. But I have seen a lot of doors slam in my face nonetheless. I know my personality is way out there and sometimes hard to take, but I will submit that if my personality did not come with big tits and a high voice, it would be much easier to "take".
Because here's the thing: I like being a girl. I love dressing up in outfits that accentuate how cute I am, and wearing makeup. I love to party, particularly if karaoke is involved. I have a lot of interests outside tech, most of which could be considered girly. I am not going to hide or deny that stuff, even though apparently it means that people -- i.e. many men in tech -- can't take me seriously because they can't fit me into a well-defined pigeonhole.
But why should I make it easy for them? Why should I fit into one of their boxes? Why should I accept someone else's definition for what I, as a woman, should be? The answer is that I shouldn't and I won't. If you give me a job to do, I will do that job well, and THAT IS WHAT COUNTS in my field or in any other.
And the last thing I need is another woman telling me that I can't, or shouldn't, try to do what I want to do and am good at because I am a woman.
Subscribe to:
Posts (Atom)