April 29, 2015 at 4:20 pm
I walked into the ST (Science and Technology) building at the local community college only to find that the bottom floor was numbered zero. 😎 I knew that I was in the right place. Oh by the way, the main entrance was on floor 1.
The dental software company, at one point, was in the basement of a shopping mall. The tenant above us was the movie theaters. They decided to replace all of the seats. The new one required new attach bolts to be place in the floor. The students in the class that I was teaching were all dental assistants. When the hammer drill was gong right over our heads someone asked what that terrible noise was. I said that there was a dentist that had moved in. They all held their jaws in sympathy. Appearance is reality? I could happen. 😀
ATBCharles Kincaid
April 30, 2015 at 9:14 am
Charles Kincaid (4/29/2015)
I walked into the ST (Science and Technology) building at the local community college only to find that the bottom floor was numbered zero. 😎 I knew that I was in the right place. Oh by the way, the main entrance was on floor 1...
I've seen C programming books that start with chapter 0.
...
-- FORTRAN manual for Xerox Computers --
April 30, 2015 at 9:28 am
jay-h (4/30/2015)
Charles Kincaid (4/29/2015)
I walked into the ST (Science and Technology) building at the local community college only to find that the bottom floor was numbered zero. 😎 I knew that I was in the right place. Oh by the way, the main entrance was on floor 1...I've seen C programming books that start with chapter 0.
That's cool! I was recently talking to someone who was doing a count of something whether that was a base of zero or one. It gave them pause.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
May 23, 2015 at 3:24 pm
Of course all of this assumes your DBA or sysadmin is beyond reproach. I worked as a bank clerk many years before I'd ever heard of SQL Server. In their training, policy and procedures they emphasised that an unhealthy number of bank frauds were perpetrated by insiders. A security measure they had in place to counter this was the concept of two signatures... And there were rules about which two and when. I've never seen the equivalent of this implemented in SQL Server. Ultimately trust always seems be vested in people who can act alone. If I wanted to set up my SQL Server environment so that certain tasks could only be performed by two people, and that their activities could always be traced, could I do it? How would I go about it?
...One of the symptoms of an approaching nervous breakdown is the belief that ones work is terribly important.... Bertrand Russell
May 25, 2015 at 8:50 am
You could lock some sysadmin functions by requiring a password split in half and known to two people so that both must be present to unlock it, each person entering half. But you'll run in to problems when one of them is out sick or otherwise unavailable. And a duplicitous person could potentially install a keylogger on their own computer to capture the other half of the password. Another possibility is one of those ever-changing number code cards, only it's kept locked up in another unit's office and must be signed out and returned promptly. You'd need for whoever manages the card to check the serial number of the card when returned to make sure the person who checked it out didn't return a different card.
In a similar vulnerability concept, large corporations have policies that don't allow multiple heads of departments or board members to travel on the same flight.
Trust is a big deal, and Microsoft is doing what they can to reduce it with database encryption so that even the DBAs don't have access to the data, with SS '16 capable of implementing full encryption: at rest and while moving between the server and the user/application. We'll see what kind of performance hit and other difficulties that that level of encryption results in.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
May 25, 2015 at 9:18 am
GPO (5/23/2015)
Of course all of this assumes your DBA or sysadmin is beyond reproach. I worked as a bank clerk many years before I'd ever heard of SQL Server. In their training, policy and procedures they emphasised that an unhealthy number of bank frauds were perpetrated by insiders. A security measure they had in place to counter this was the concept of two signatures... And there were rules about which two and when. I've never seen the equivalent of this implemented in SQL Server. Ultimately trust always seems be vested in people who can act alone. If I wanted to set up my SQL Server environment so that certain tasks could only be performed by two people, and that their activities could always be traced, could I do it? How would I go about it?
I have seen systems where certain tasks require two people sitting side by side. They use a special ID that is checked out from an application that generates a new split password at the time the ID is required for use, and the password expires in 24 hours or less. There is usually a group of 3 or more people with the ability to check out the passwords, so it's not an issue if someone is on vacation.
May 25, 2015 at 9:35 am
Ross McMicken (5/25/2015)
GPO (5/23/2015)
Of course all of this assumes your DBA or sysadmin is beyond reproach. I worked as a bank clerk many years before I'd ever heard of SQL Server. In their training, policy and procedures they emphasised that an unhealthy number of bank frauds were perpetrated by insiders. A security measure they had in place to counter this was the concept of two signatures... And there were rules about which two and when. I've never seen the equivalent of this implemented in SQL Server. Ultimately trust always seems be vested in people who can act alone. If I wanted to set up my SQL Server environment so that certain tasks could only be performed by two people, and that their activities could always be traced, could I do it? How would I go about it?I have seen systems where certain tasks require two people sitting side by side. They use a special ID that is checked out from an application that generates a new split password at the time the ID is required for use, and the password expires in 24 hours or less. There is usually a group of 3 or more people with the ability to check out the passwords, so it's not an issue if someone is on vacation.
I like that. And naturally the act of checking out a password would be heavily logged and audited. I have no idea how I'd try to implement something like that in SQL Server, probably a PowerShell or CLR app I suppose.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
May 26, 2015 at 8:01 am
Wayne West (5/25/2015)
Ross McMicken (5/25/2015)
GPO (5/23/2015)
Of course all of this assumes your DBA or sysadmin is beyond reproach. I worked as a bank clerk many years before I'd ever heard of SQL Server. In their training, policy and procedures they emphasised that an unhealthy number of bank frauds were perpetrated by insiders. A security measure they had in place to counter this was the concept of two signatures... And there were rules about which two and when. I've never seen the equivalent of this implemented in SQL Server. Ultimately trust always seems be vested in people who can act alone. If I wanted to set up my SQL Server environment so that certain tasks could only be performed by two people, and that their activities could always be traced, could I do it? How would I go about it?I have seen systems where certain tasks require two people sitting side by side. They use a special ID that is checked out from an application that generates a new split password at the time the ID is required for use, and the password expires in 24 hours or less. There is usually a group of 3 or more people with the ability to check out the passwords, so it's not an issue if someone is on vacation.
I like that. And naturally the act of checking out a password would be heavily logged and audited. I have no idea how I'd try to implement something like that in SQL Server, probably a PowerShell or CLR app I suppose.
I can see how a DBA would like this. It would certainly cut down on the number of ad-hoc queries and after hours logins.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 26, 2015 at 8:16 am
Eric M Russell (5/26/2015)
Wayne West (5/25/2015)
Ross McMicken (5/25/2015)
GPO (5/23/2015)
Of course all of this assumes your DBA or sysadmin is beyond reproach. I worked as a bank clerk many years before I'd ever heard of SQL Server. In their training, policy and procedures they emphasised that an unhealthy number of bank frauds were perpetrated by insiders. A security measure they had in place to counter this was the concept of two signatures... And there were rules about which two and when. I've never seen the equivalent of this implemented in SQL Server. Ultimately trust always seems be vested in people who can act alone. If I wanted to set up my SQL Server environment so that certain tasks could only be performed by two people, and that their activities could always be traced, could I do it? How would I go about it?I have seen systems where certain tasks require two people sitting side by side. They use a special ID that is checked out from an application that generates a new split password at the time the ID is required for use, and the password expires in 24 hours or less. There is usually a group of 3 or more people with the ability to check out the passwords, so it's not an issue if someone is on vacation.
I like that. And naturally the act of checking out a password would be heavily logged and audited. I have no idea how I'd try to implement something like that in SQL Server, probably a PowerShell or CLR app I suppose.
I can see how a DBA would like this. It would certainly cut down on the number of ad-hoc queries and after hours logins.
Heh. Not a problem for my system: the people who can do ad hoc queries will have their own local copy of the database and will be VERY few in numbers, and the VM that runs the server pauses itself at 7pm weeknights, possibly earlier once I determine usage patterns when it starts going live in a few months.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
May 26, 2015 at 10:03 am
Wayne West (5/25/2015)
Ross McMicken (5/25/2015)
GPO (5/23/2015)
Of course all of this assumes your DBA or sysadmin is beyond reproach. I worked as a bank clerk many years before I'd ever heard of SQL Server. In their training, policy and procedures they emphasised that an unhealthy number of bank frauds were perpetrated by insiders. A security measure they had in place to counter this was the concept of two signatures... And there were rules about which two and when. I've never seen the equivalent of this implemented in SQL Server. Ultimately trust always seems be vested in people who can act alone. If I wanted to set up my SQL Server environment so that certain tasks could only be performed by two people, and that their activities could always be traced, could I do it? How would I go about it?I have seen systems where certain tasks require two people sitting side by side. They use a special ID that is checked out from an application that generates a new split password at the time the ID is required for use, and the password expires in 24 hours or less. There is usually a group of 3 or more people with the ability to check out the passwords, so it's not an issue if someone is on vacation.
I like that. And naturally the act of checking out a password would be heavily logged and audited. I have no idea how I'd try to implement something like that in SQL Server, probably a PowerShell or CLR app I suppose.
The app used to check out ID's is just a .NET app that assigns a password via LDAP calls (I think, that's not my area of expertise). The user id's are set up in advance with appropriate parameters for how much approval is required, whether it's a split password, etc. Data is stored in a SQL server backend. You can apply this to any application that uses active directory for authentication.
Lots of logging and auditing, reports for management to review, etc.
May 27, 2015 at 1:26 am
The split password and side-by-side authentication reminds me of the old days under ground when we both had to turn our key at the same time. :w00t:
ATBCharles Kincaid
September 26, 2019 at 1:24 pm
I'm a bit shocked by "We require strong passwords, we require frequent password changes, and more often than we used to we add two-factor/multi-factor authentication to the mix" and don't know how I missed it four years and a few months ago.
The last thing we want to build a secure system is frequent password changes. Frequent password changes just about guarantee that passwords will not be adequately strong and/or will be written down somewhere handy rather that remembered or held in a secure password safe, so it is in effect in direct conflict with the requirement for strong passwords. Mutli-factor authentication on the other hand is extremely useful.
I think it extremely unlikely that a Duress Password will be a good idea unless there is enough funding (and ongoing support) to provide (a) a convincing imitation of the real system and (b) non-trivial amounts of time before the obtainer of the password realises he has been had and (c) a useful trace of whoever falls into the fake system. As the cost of doing even half of this properly will be vast it will be extremely rare for a Duress Password to be a sensible approach.
Tom
September 26, 2019 at 1:43 pm
The office park where I work happens to be located in a city where everyone is required to carry to carry a gun.
https://www.cnn.com/2018/03/06/us/kennesaw-georgia-gun-ownership/index.html
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 28, 2019 at 11:43 pm
Why not, just to be safe have a distress login for All Admins with permissions of Domain Admin and higher. I suggest user name "1@mh0$t@ge" and password "!C@11TheC0p$" and have alerts setup.
If anyone is dumb enough to try it they should be easy to catch 🙂
Darwin's survival of the fittest ...
Viewing 14 posts - 46 through 58 (of 58 total)
You must be logged in to reply to this topic. Login to reply