joi, 30 iunie 2016

Fragmente Jurnal XCI - Comentariu la Aforismul IX

Aforismul IX:

Dumnezeu nu inventat și nici nu a descoperit Lumea, ci a creat-o; Dumnezeu este un artist și, ca orice artist, își iubește Opera. 


Dumnezeu nu inventat şi nici nu a descoperit Lumea, ci a creat-o. Iar dacă Dumnezeu a creat Lumea - şi nu a inventat-o - înseamnă ce nu i-a dat un alt scop decât  frumuseţea. Ne bucurăm câteodată şi noi de frumuseţea ei amară cu ochii şi sufletele deschise şi "bucuroase de moarte" (Tudor Arghezi), dar mai mult îi admirăm mecanicitatea - până într-acolo încât ni-L imaginăm pe Dumnezeu că pe un priceput ceasornicar - şi o jefuim fără ruşine şi fără măsură. Dumnezeu singur o iubeşte pur-şi-simplu, căci dacă nu pentru propria-i plăcere sau folosinţă, pentru ce altceva ar fi creat Lumea, dacă nu pentru a o iubi? Perpetuitatea şi prepotenţa Lui elimina bănuiala angajării Sale într-o luptă dezolantă cu moartea sau cu neantul. Totuşi, chiar dacă Lumea este artă fertilă - fără utilitate - pentru Dumnezeu, ea există pentru oameni şi oamenii există în ea. Prin prisma Creaţie, oare noi - oamenii - suntem parte din Lume? Cât ne-am bucura să putem spune că Dumnezeu a inventat lumea pentru noi, pentru că ne iubeşte, iar pe lista Creaţiei noi suntem primii, măcar ca importanţă. Nu avem însă decât certitudinea că Dumnezeu este un artist şi, ca orice artist capricios, îşi iubeşte cu egoism şi egocentrism Opera.


marți, 14 iunie 2016

Auditie - Daria Ioana Vasiliu

Ballade pour Adeline - Daria Ioana Vasiliu



Napolitan Dance - Daria Ioana Vasiliu


sâmbătă, 11 iunie 2016

Tactical approach on IT security audits: “Follow the data” (Processes should be the center of IT Security audits)


Motto: "Technology follows the same rule of evolution 
as any other live form" Freeman Dyson





I was asked many times - and I have debated it with my colleagues since I’d started my career in (IT Security Audit) domain! - what is the best tactical approach on IT security audits.

When you are arriving to a client…
(1) you have a checklist in your pocket – basically, every security standards or guidelines come with set of items (that has to be checked) in a form of a non-structured list -,
(2) you encounter on the field some people with some level of IT experience (and some level of communication skills) and  
(3) you are facing an IT infrastructure - a mixture of hardware and software (which you do not know too well what it’s supposed to do).

You have three options:

(1) First option – “Paper audit” (as I call it): You could follow each and every item from your security checklist (in the exact order), jumping from one person to another (forth and back) and from one equipment to another, trying to find the best answer. In this way you think that you will cover the whole scope of the guideline or standard,

  (1.1) But everybody should agree that this is a fallacious argument.
  (1.1.1) The terms in which the questions/items are formulated are usually too general (and sometime people cannot even understand them) and
  (1.1.2) the answer to one question/item is composed from many pieces scattered throughout the entire client’s company.

  (1.2) And even if you can go through all the items from checklist you cannot say,
  (1.2.1) that you really addressed all the IT security topics and
  (1.2.2) that you (and respectively your client) understood the IT security challenges faced by the client. 
  (1.2.3) And more than that, (3) you cannot make real recommendations for improvement.


(2) Second option – “IT is binary” (as I call it):  You could ask for the IT architecture documentation (from outlets to applications) and start the assessment of each component’s security level (from technological point of view). You have at your disposal a large variety of tools that can help you in this endeavor. You can use Nessus/OpenVas (for example) or, (if the client really wants to know if he is vulnerable) Metasploit Framework (another example).

But the downfall of this approach is that it provides no real usable output. It doesn’t mean that the output is false or anything, but it’s not knowledge, it’s only information. And this is because:
(2.1)  first: you cannot fully understand the role played by a single piece of hardware or software (and you cannot pretend that you did it only by probing it with your fancy tools, even if you have years of experience!). The hardware and software are combined into (sometimes extremely complicated) systems; with the systems the company is providing IT services; the IT services are offered and maintained with the help of processes; the processes are sets of activities performed by people. You are only looking at the bottom of the pyramid. And :" you cannot say the taste of fruits/only by staring at the roots".
(2.2) and second: you can only see vulnerabilities and not threats. Missing the context and the big picture, will make you blind to the real client company exposure to IT security risks. Or it will make you look paranoiac.


(3) And the last option: “Going after the people” (as I call it):  You could select relevant persons from different departments and discuss with them IT security topics. If you have enough charisma and you ask the right questions you may end up closer to the truth, because the people will explain how they are using the technology. In this way you could discover (eventually) the information flow and how this information is handled by people (in IT environment) at each step. (By-the-way: If you are not dealing with machine learning and/or AI, you should not accept data processing without a human decision and human responsibility). However, it is not certain that you will reach your goals. If the IT components cannot tell the full story, it is also true for people. People can have more knowledge, but they do not have the whole knowledge.


(4) And this is how we arrive to the 4th option: “Follow the data” (as I call it):  The principle that governs this approach is the following:
The company (the subject of audit) is bringing value to his clients thorough the mean of IT services. These IT services are in fact nothing else then ways to create, store, move data using processes (a set of predefined activities). 

You – as an auditor – have to see the company not as an old and hierarchical structure (teams, departments, organizations, etc…), but as a mesh of pipelines through which the data is passing. IT security means that
(4.1.1) you have to understand the importance of the fluid (a metaphor of data) and
(4.1.2) you have to check the integrity of the pipelines.

If you want to conduct a successful and useful IT security audit, you have to put in the center of your audit  - processes (and, respectively, the resources and the capabilities that make the processes possible). You have to change the audit scope. In this way you will understand
(4.2.1) the data importance and the data flow and
(4.2.2) you will act in the spirit of security standards/regulations/law, not in their dead letter.

So start any IT audit by asking the responsible persons for the list of processes that are implemented in the company or try to discover them (if they are not documented already)! When you will understand all the client processes, you will also understand
(4.3.1) what security questions are relevant and should receive answers and – equally important –
(4.3.) to whom you should address the questions.

After that, any of the other approaches (“Paper audit”, “IT is binary” or “Going for the people”) (or any combination of them – my warm recommendation!) will provide good results, because now they will serve the purpose of clarifying the security of the client processes, (client data and client business).

And in the end this is what the term “information security” means and this is what matters the most…