I just spent a bit digging into that company just now. You can figure out a good portion of their software stack from their IT employee profiles on LinkedIn, btw.
Given that their org is mainly composed of attorneys, it is probably a safe bet to say they are Governance, Risk and Compliance (GRC) top-heavy. This almost always results in security-by-spreadsheet and poor classification of risk. While I am sure their broad risks are well documented and tracked, it’s highly unlikely that real issues get the time of day because those don’t make for meetings senior managers can understand.
In this drive for pristine paperwork, they likely have compliance reports for all of their larger customers. This generally includes all applications used, how servers are secured and how often they are patched, access control lists, detailed network diagrams and much, much more. That documentation probably also has all application and database “interface” lists, what ports they are running on and how those service accounts are maintained. Best of all, they likely have lists of “security exceptions”, or security issues that are in the process of getting fixed… Just to reiterate, this is not only for Orrik, but any of their customers they have done security reviews for.
Without a doubt, their IT and security staff is minimal. When everything is in the cloud, it’s somebody else’s problem, amirite?
It makes me chuckle a little to see GRC folk get taken down a few notches in organizations like these.
I remember when I realized that the lawyers had taken over cybersecurity. It was 2018. I was in a meeting, looked around, and realized that I was the only person in the room who codes or has ever coded, and also the only person without formal certifications in security. 5 years earlier, security teams were full of people from all walks of life, who often got into security from (let’s call it) “practical” experience.
Thankfully, that really depends on the org. I started in security before “security engineer” was a thing. It was different times, for sure. When the 2008 housing bubble popped, banks started the trend of splitting out engineering roles from the newly formed risk and governance groups. This eventually morphed into what we have today: Security engineering teams and separate GRC/Legal teams.
I can’t hate on compliance too much through. If ran correctly, tracking and auditing networks and processes is an extremely important thing to do.
I just learned both worlds over the years. At my age, I have the technical experience to hold my own and also the balls to push back on stupid compliance requirements to people very high up in organizations. (The trick is to not give a fuck about getting fired for speaking my mind.)
Sorry. Went on a bit of a tangent to say “I understand you completely.” ;)
Haha, no worries, and totally agreed. I’m finding that more and more, not only is there no security engineering team, but the legal side of security has no concept of that whatsoever. They are the security team. Security, to them, is fundamentally a compliance process, which of course involves coordinating and working with the engineering team, but it isn’t really a technical practice so much as a managerial and administrative one.
I just spent a bit digging into that company just now. You can figure out a good portion of their software stack from their IT employee profiles on LinkedIn, btw.
Given that their org is mainly composed of attorneys, it is probably a safe bet to say they are Governance, Risk and Compliance (GRC) top-heavy. This almost always results in security-by-spreadsheet and poor classification of risk. While I am sure their broad risks are well documented and tracked, it’s highly unlikely that real issues get the time of day because those don’t make for meetings senior managers can understand.
In this drive for pristine paperwork, they likely have compliance reports for all of their larger customers. This generally includes all applications used, how servers are secured and how often they are patched, access control lists, detailed network diagrams and much, much more. That documentation probably also has all application and database “interface” lists, what ports they are running on and how those service accounts are maintained. Best of all, they likely have lists of “security exceptions”, or security issues that are in the process of getting fixed… Just to reiterate, this is not only for Orrik, but any of their customers they have done security reviews for.
Without a doubt, their IT and security staff is minimal. When everything is in the cloud, it’s somebody else’s problem, amirite?
It makes me chuckle a little to see GRC folk get taken down a few notches in organizations like these.
I remember when I realized that the lawyers had taken over cybersecurity. It was 2018. I was in a meeting, looked around, and realized that I was the only person in the room who codes or has ever coded, and also the only person without formal certifications in security. 5 years earlier, security teams were full of people from all walks of life, who often got into security from (let’s call it) “practical” experience.
Thankfully, that really depends on the org. I started in security before “security engineer” was a thing. It was different times, for sure. When the 2008 housing bubble popped, banks started the trend of splitting out engineering roles from the newly formed risk and governance groups. This eventually morphed into what we have today: Security engineering teams and separate GRC/Legal teams.
I can’t hate on compliance too much through. If ran correctly, tracking and auditing networks and processes is an extremely important thing to do.
I just learned both worlds over the years. At my age, I have the technical experience to hold my own and also the balls to push back on stupid compliance requirements to people very high up in organizations. (The trick is to not give a fuck about getting fired for speaking my mind.)
Sorry. Went on a bit of a tangent to say “I understand you completely.” ;)
Haha, no worries, and totally agreed. I’m finding that more and more, not only is there no security engineering team, but the legal side of security has no concept of that whatsoever. They are the security team. Security, to them, is fundamentally a compliance process, which of course involves coordinating and working with the engineering team, but it isn’t really a technical practice so much as a managerial and administrative one.