4 ms·

In a large company, a company with sufficiently-sensitive data (where loss is a legal matter), or a company with a lot of money to lose (financial processing),

In a large company, a company with sufficiently-sensitive data (where loss is a legal matter), or a company with a lot of money to lose (financial processing), having a dedicated security team might make sense and might be worth the money, but in most situations, I think it does more harm than good. Security teams rarely know how applications work, so their approach to security is heavy-handed and provides a false sense of protection. It's more important to instill everyone with security-minded philosophy, so that applications and systems are designed with security in mind from the beginning. Firewalls, packet inspection, virus scanning, and the like would all be completely unnecessary if code was written securely and if human beings behaved properly. Of course these things don't happen, and of course firewalls and scans and the like are common-sense protections, but most data loss is caused by poorly-designed applications which run in very secure environments. Dedicated security teams simply aren't in a position to identify and solve problems like buffer overruns or SQL injection.

pbhjpbhj 9y ago
>Security teams rarely know how applications work, // I'm amazed if anyone working in a computer security role doesn't know about SQL injection attacks and their mitigations. You'll be telling me they don't know about salting passwords next??
- taway1929293 9y ago
  Where I work, yes, the security teams don't know how applications work. we have a dedicated security team - they run nessus scans for compliance and network scans and hand them to managers and executives who hand them to us. they explicitly don't touch the code - a senior guy has declared that he's not responsible on that level, that he's 'no coder' in response to a shell injection vulnerability. so he knows 'about' salting passwords but he probably couldn't verify if they are salted or not. To me it's left the impressions that 1) security is mostly theater and 2) 'security engineer' is a meaningless title - it can mean anything from 'runs scans' to 'network administrator' to 'penetration tester' to 'good engineer'. unfortunately my default attitude towards the title has been "i'm probably dealing with a charlatan"
  - eftychis 9y ago
    Calling this security engineering is a misnomer. Yes, I agree the way you describe it this is pure theater. I take a bit of a long position, please bear with me: A lot of engineering is plagued by the notion of theater, forced either by outer or inner (see management) pressure to project an image. Examples: "Everything you see is rendered online", "our investing plan is done by this awesome bot" etc. With security really a lot of times it is hard for people to see the incentive. Loss is hard to quantify for people and then there is the extreme optimism. "Oh we are using TLS and we have our data on AWS, we do not need anything else." It is a field, that is hard to quantify that focuses on rare events. And then consumers just don't care about non-tangible things like their data till it's too late. What happened to Equifax? If Equifax had lost directly an equal amount of money to the damages it will/has caused with the data loss, response of the public would be more drastic and there would be civil charges at least. Same for Trustico. A guy decided it is ok to send a crazy amount of secrets over email. Then people realize the guys expose the freaking shell and root. And now Trustico is back in business (still unbelievable to me...). Thus companies have little pressure to do the job right. And companies tend to satisfy the minimum necessary requirements. A final reason also: too little supply. This field has a lot of specialization and there is a bunch of theory and skills required. And on top of that you need to have a good understanding and skills from the other fields you touch (e.g. linking, compilers, web development, distributed systems,...) Similarly, to be a graphics engineer you need to know some computational geometry and then a bunch of extra stuff depending on your specialty. I think it is hard for someone to pose as a games engine engineer and have no idea about convex hull operations. However, due to the reasons above a person can pose as a security oriented engineer and say a couple of hot words and get a job in some companies. And from experience management is filled with people like "What why aren't we encrypting passwords?" or "We need to have an option for people to opt out during clientHello and just use HTTP." Regarding your senior guy: He is not a security engineer or whatever. The way you describe the situation and taking a positive vantage point, I think the management had to sell to some outsider that they care about security and hired a penetration tester maybe gave him a title that could as well be "Lord of the Stars and Black Holes" and went on with their lives. Why? Because they are not accountable regarding this view of the product. It's hard to bullshit people about an app that is not working. It is easy to bullshit people about an app that is barely functional and sends their data to the pockets of third parties. From personal experience that is not the case for some serious companies. And there are some extremely good security engineers/cryptographers/... engineers out there.
- candiodari 9y ago
  Of course, that is trivial superficial stuff. It's akin to checking if the door of a car is open. Should it be done ? Perhaps (assuming you're using SQL at all), but let's not pretend an app is secure just because an attempt at SQL injection fails.
user5994461 9y ago
>>> Dedicated security teams simply aren't in a position to identify and solve problems like buffer overruns or SQL injection. Yes they are. That's exactly two of their purpose. You'd be amazed what an automatic scanner and a manual edit of the service url "/log?name=/etc/password" can uncover.
unethical_ban 9y ago
This whole post reeks of developer arrogance. >Security teams rarely know how applications work, so their approach to security is heavy-handed and provides a false sense of protection. Yes, sometimes there are overly bureaucratic processes in place, but as a security guy, do you know how many times we see devs self-SQL injecting themselves on a webpage? How many times they ask if their service needs to be in the DVZ? (What the fuck is that; I think they mean DMZ)? Or Why it's a problem that they're asking why they can't have "The Internet" when I ask what services their server needs externally? Don't act like devs (or even IT Ops as a whole) has their shit together. They're at LEAST as security-crippled as security EVER is over-paranoid. And as for this... >Firewalls, packet inspection, virus scanning, and the like would all be completely unnecessary if code was written securely and if human beings behaved properly. First, code will never be written completely securely; second, security is a spectrum of mitigation therefore ACLS/firewalls/scanning will ALWAYS be necessary; third, humans NEVER behave properly, inside or out therefore security will always be in business.
- deleted 9y ago
  [deleted]

pbhjpbhj 9y ago

>Security teams rarely know how applications work, // I'm amazed if anyone working in a computer security role doesn't know about SQL injection attacks and their mitigations. You'll be telling me they don't know about salting passwords next??

taway1929293 9y ago
Where I work, yes, the security teams don't know how applications work. we have a dedicated security team - they run nessus scans for compliance and network scans and hand them to managers and executives who hand them to us. they explicitly don't touch the code - a senior guy has declared that he's not responsible on that level, that he's 'no coder' in response to a shell injection vulnerability. so he knows 'about' salting passwords but he probably couldn't verify if they are salted or not. To me it's left the impressions that 1) security is mostly theater and 2) 'security engineer' is a meaningless title - it can mean anything from 'runs scans' to 'network administrator' to 'penetration tester' to 'good engineer'. unfortunately my default attitude towards the title has been "i'm probably dealing with a charlatan"
- eftychis 9y ago
  Calling this security engineering is a misnomer. Yes, I agree the way you describe it this is pure theater. I take a bit of a long position, please bear with me: A lot of engineering is plagued by the notion of theater, forced either by outer or inner (see management) pressure to project an image. Examples: "Everything you see is rendered online", "our investing plan is done by this awesome bot" etc. With security really a lot of times it is hard for people to see the incentive. Loss is hard to quantify for people and then there is the extreme optimism. "Oh we are using TLS and we have our data on AWS, we do not need anything else." It is a field, that is hard to quantify that focuses on rare events. And then consumers just don't care about non-tangible things like their data till it's too late. What happened to Equifax? If Equifax had lost directly an equal amount of money to the damages it will/has caused with the data loss, response of the public would be more drastic and there would be civil charges at least. Same for Trustico. A guy decided it is ok to send a crazy amount of secrets over email. Then people realize the guys expose the freaking shell and root. And now Trustico is back in business (still unbelievable to me...). Thus companies have little pressure to do the job right. And companies tend to satisfy the minimum necessary requirements. A final reason also: too little supply. This field has a lot of specialization and there is a bunch of theory and skills required. And on top of that you need to have a good understanding and skills from the other fields you touch (e.g. linking, compilers, web development, distributed systems,...) Similarly, to be a graphics engineer you need to know some computational geometry and then a bunch of extra stuff depending on your specialty. I think it is hard for someone to pose as a games engine engineer and have no idea about convex hull operations. However, due to the reasons above a person can pose as a security oriented engineer and say a couple of hot words and get a job in some companies. And from experience management is filled with people like "What why aren't we encrypting passwords?" or "We need to have an option for people to opt out during clientHello and just use HTTP." Regarding your senior guy: He is not a security engineer or whatever. The way you describe the situation and taking a positive vantage point, I think the management had to sell to some outsider that they care about security and hired a penetration tester maybe gave him a title that could as well be "Lord of the Stars and Black Holes" and went on with their lives. Why? Because they are not accountable regarding this view of the product. It's hard to bullshit people about an app that is not working. It is easy to bullshit people about an app that is barely functional and sends their data to the pockets of third parties. From personal experience that is not the case for some serious companies. And there are some extremely good security engineers/cryptographers/... engineers out there.
candiodari 9y ago
Of course, that is trivial superficial stuff. It's akin to checking if the door of a car is open. Should it be done ? Perhaps (assuming you're using SQL at all), but let's not pretend an app is secure just because an attempt at SQL injection fails.

user5994461 9y ago

>>> Dedicated security teams simply aren't in a position to identify and solve problems like buffer overruns or SQL injection. Yes they are. That's exactly two of their purpose. You'd be amazed what an automatic scanner and a manual edit of the service url "/log?name=/etc/password" can uncover.

unethical_ban 9y ago

This whole post reeks of developer arrogance. >Security teams rarely know how applications work, so their approach to security is heavy-handed and provides a false sense of protection. Yes, sometimes there are overly bureaucratic processes in place, but as a security guy, do you know how many times we see devs self-SQL injecting themselves on a webpage? How many times they ask if their service needs to be in the DVZ? (What the fuck is that; I think they mean DMZ)? Or Why it's a problem that they're asking why they can't have "The Internet" when I ask what services their server needs externally? Don't act like devs (or even IT Ops as a whole) has their shit together. They're at LEAST as security-crippled as security EVER is over-paranoid. And as for this... >Firewalls, packet inspection, virus scanning, and the like would all be completely unnecessary if code was written securely and if human beings behaved properly. First, code will never be written completely securely; second, security is a spectrum of mitigation therefore ACLS/firewalls/scanning will ALWAYS be necessary; third, humans NEVER behave properly, inside or out therefore security will always be in business.

deleted 9y ago
[deleted]