« May »
SunMonTueWedThuFriSat
1234567
891011121314
15161718192021
22232425262728
293031    
       
About
Categories
Recently
Syndication
Locations of visitors to this page

Powered by blojsom

Radovan Semančík's Weblog

Friday, 27 May 2016

It isn't. That's how it is. Why? Take any study describing potential information security threats. What do you see among the top threats there? Take another study. What do you see there? Yes. That's the one. It is consistently marked as one of the most serious threats in vast majority of studies published for (at least) last couple of decades. Yet it looks like nobody really knows what to do about this threat. So, who is this supervillain? He's right under your nose. It is the insider.

It all makes perfect sense. The employee, contractor, partner, serviceman - they all are getting the access rights to your systems easily and legally. But, do you really know who has access to what? Do you know that the access is still needed? Maybe this particular engineer was fired yesterday, but he still has VPN access and administration rights to the servers. And as he might not be entirely satisfied by the way how he has left the company the chances are he is quite inclined to make your life a bit harder. Maybe leaking some of the company records to which he still has the access would do the trick? It certainly will. And who is the one to blame for this? Is the security officer doing his job properly? Do we know who has access to what right now? Do we know if the access is legal? Are we sure there are no orphaned accounts? Are we sure there are no default or testing accounts with trivial passwords? Can we disable the accounts immediately? Maybe we can disable password authentication, but are you sure that there is no other way around that? What about SSH keys? What about email-based or help-desk password resets?

If you do not have good answers to these questions then your information security is quite weak. I'm sorry. That's how it really is. Do you remember that weakest link idiom that is taught in every information security training? Now you know where your weakest link is.

But what to do about it? Obviously, you need to manage the access. So maybe the Access Management (AM) software can help here? Actually, the primary purpose of Access Management software is not security. The AM purpose is to make user's life easier by implementing convenience mechanisms such as single sign-on (SSO). Yes, AM might improve the authentication by adding a second factor, making the authentication adaptive and so on. But that won't help a bit. Authentication is not your problem. The insider already has all the credentials to pass the authentication. He got the credentials legally. So even the strongest authentication mechanism in the world will do absolutely nothing to stop this attack. No, authentication is not the problem and therefore Access Management is not going to make any significant difference.

The root of the problem is not in authentication, authorization, encryption or any other security buzzword. It is plain old management issue. The people have access where they should not have access. That's it. And what turns this into a complete disaster is lack of visibility: the people responsible for security do not know who has access to what. Therefore improvements in "information security proper" are not going to help here. What needs to be improved is the management side. Management of the identities and access rights. And (surprise surprise) there is a whole field which does right that: Identity Management (IDM).

Therefore there is no real security without Identity Management. I mean it. And I've been telling this for years. I though that everybody knows it. But obviously I was wrong. So recently I have been putting that openly in my presentations. But still everybody is crazy about deploying Access Management, SSO and OpenID Connect and OAuth and things like that. And people are surprised that it costs a fortune an yet it will not bring any substantial security improvement. Don't get me wrong, I'm not telling you that the AM technologies are useless. Quite the contrary. But you need to think how to manage them first. Implementing SSO or OAuth without identity management is like buying a super expensive sport car with an enormous engine but completely forgetting about steering wheel.

Don't make such dangerous and extremely expensive mistakes. Think about identity management before heading full speed into the identity wilderness.

(Reposted from Evolveum blog)

Technorati Tags:

Posted by rsemancik at 2:16 PM in Identity
Wednesday, 18 May 2016

Test-Driven Development (TDD) tells us to write the tests first and only then develop the code. It may seem like a good idea. Like a way how to force lazy developers to write tests. How to make sure that the code is good and does what it should do. But there's the problem. If you are doing something new, something innovative, how the hell are you supposed to know what the code should do?

If you are doing something new you probably do not know what will be the final result. You are experimenting, improving the code, changing the specification all the time. If you try to use TDD for that you are going to fail miserably. You will have no idea how to write the tests. And if you manage to write it somehow you will change them every time. This is a wasted effort. A lot of wasted effort. But we need the tests, don't we? And there is no known force in the world that will make the developer to write good and complete tests for the implementation once the implementation is finished. Or ... is there?

What are we using in midPoint project is Test-Driven Bugfixing (TDB). It works like this:

  1. You find a bug.
  2. You write an (automated) test that replicates the bug.
  3. You run the test and you check that the test is failing as expected.
  4. You fix the bug.
  5. You run the test and you check that the test is passing.

That's it. The test remains in the test suite to avoid future regressions. It is a very simple method, but a very efficient one. The crucial part is writing the test before you try to fix the bug. Even if the bugfix is one-liner and the test takes 100 lines to write. Always write the test first and see that it fails. If you do not see this test failure how can you be sure that the tests replicates the bug?

We are following this method for more than 5 years. It works like a charm. The number of tests is increasing and we currently have several times more tests that our nearest competition. Also the subjective quality of the product is steadily increasing. And the effort to create and maintain the tests is more than acceptable. That is one of the things that make midPoint great.

(Reposted from Evolveum blog)

Technorati Tags:

Posted by rsemancik at 5:18 PM in Software
Wednesday, 11 May 2016

I like OpenLDAP. OpenLDAP server is famous for its speed and good open source character. But it is really infamous for ease of management. Or rather a lack of anything that could be called "easy" when it comes to managing OpenLDAP. Managing OpenLDAP content is not that difficult. For manual management there is excellent Apache Directory Studio. For automated management and synchronization there is our very own midPoint. No, it is not the content that is a problem. It is the configuration.

OpenLDAP has a really cool but quite cumbersome and very under-documented OLC-style configuration. It is configuration of LDAP server using the LDAP protocol, which seems to become quite a standard feature of all good LDAP servers. But it is really a pain to use that in practice: you have to prepare LDIF file, figure out the correct DN, compose a long ldapmodify command-line, etc. Not very practical at all. But what about this?

$ sudo slapdconf list-suffixes
dc=evolveum,dc=com
dc=example,dc=com
$ sudo slapdconf get-suffix-prop dc=example,dc=com
olcDatabase : {2}mdb
olcDbDirectory : /var/lib/ldap/example
.... (shortened for clarity) ....
$ sudo slapdconf set-server-prop idle-timeout:120
$ sudo slapdconf get-server-prop
olcIdleTimeout : 120
olcLogLevel :
  stats
  stats2

This is my micro-project slapdconf. Very handy tool. If have been using it and maintaining it for last two years, but some parts go back more than 10 years. But now I'm looking for a help with this little project. Firstly, it is written in Perl. Perl was the cool thing when this all started. I'm an old Perl monk and when you have a hammer every problem looks like a nail. So I've nailed it in Perl. But despite the long-awaited Perl 6 release the Perl is not a very suitable tool any more. So I'm looking for someone that is fluent in Python to rewrite these little scripts in Python. I can maintain them in Python, but I'm not confident enough to get the right Python style when starting from scratch. I'm also looking for someone who would help me to properly package this in deb packages so it can be easily distributed. Anyone willing to help?

(Reposted from Evolveum blog)

Technorati Tags:

Posted by rsemancik at 8:49 PM in Identity