Re: Security vs. Simplicity

[Aarón Mizrachi <unmanarc () gmail com>]

On Martes 26 Mayo 2009 19:40:06 Craig S. Wright escribió:
> > but blackbox are vulnerable in time since:
> >
> > - When you modify their enviroment, you dont know what is the behavior of
>
> such
> device/system...
>
> > - Every software/library/something could have discovered vulns across the
>
> time.
>
> > - Every product have a lifetime, if you dont know the exact behavior, it
>
> cannot be replaced easily, and could lead to Denial Of Service.
>
> > - etc.
>
> To an extent all software is a blackbox. The analysis of software is an NP
> infeasible problem. Turning and then Distraka demonstrated proofs that the
> state of a system can never be fully known. You are making presumptions as
> to the level of knowledge an open system holds and as to the level of
> testing.

Im not implying anything about open systems with my comments... You are taking 
extremes....

Everyone know that there is no 100% secure system.
We can cover most of the vulnerabilities, and its our job. 

> Crystal box testing is a better option. I have published papers on this in
> the past. What you are missing is the complexity/simplicity issue. You are
> mixing these issues with security.

Again...

the issue comes from not well documented systems... that are a source of 
vulnerabilities, by the exposed reasons.

you said that documentation are a source of complexity, i think, that is a 
source of simplicity. (Only if is well documented)

--------

Supose that you have a linux with mysql and you are an average admin.
What is the simplest way to change passwords?

1. google Linux; uname -a; google Change Ubuntu Linux password; read and read 
and read, and do passwd; then, check for superusers, then, check the state of 
mysql, and google it for change mysql root password... probably you need to 
install something like phpmyadmin to manage mysql and check for another 
important users... And probably, the dependant systems will stop to work... 
Then, you have to check third party systems that work with this database 
password... 

or

2. Read a security documentation on section maintenance; search for change 
system passwords; and follow the instructions.

What is more simple for maintenance?

> You also never know the state of an open system. You just have a lower cost
> of testing and rectification.
>
> As for DoS. There is always a way to DoS a system. The issue here is how
> much evidence you create and why you do it. Hit any system with a sustained
> attack from 1,000,000 bots and it goes down. End of story. This is not an
> argument about complexity impacting security.

There is a difference between DoS created by flooding or by exploiting some 
vuln... 

You could reduce the impact of some DDoS attacks, not 100% effective.
But, when the DoS comes by the software vulnerability, this is unacceptable in 
security matter... or not?. 

> Regards,
> ...
> Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> Information Defense Pty Ltd
>
>
>
> -----Original Message-----
> From: Aarón Mizrachi [mailto:unmanarc () gmail com]
> Sent: Wednesday, 27 May 2009 9:32 AM
> To: craig.wright () information-defense com
> Cc: security-basics () securityfocus com; 'Stephen Mullins';
> dan.crowley () gmail com
> Subject: Re: Security vs. Simplicity
>
> * PGP Signed by an unknown key
>
> On Martes 26 Mayo 2009 18:08:58 Craig S. Wright escribió:
> > "The answer of this question is: There is a delicate balance."
> > There is a point solution that makes a balance. Security is a dynamical
> > (spelt correctly) system. Although point equilibria exist, they do not
> > exist in time.
> >
> > Nodal minima do exist - sometimes for long periods of time, but these
> > require tuning and updates.
> >
> > " blackboxes are prone to be vulnerable "
> > Not necessarily. There are many B2 and higher (on the old rainbow table
> > US classification scheme) systems that can operate as a black box. These
> > can be fit for purpose designed systems. For instance, you can even
> > create a secure software based system using vulnerability prone software.
> >
> > I created a proof of concept system that was a secure black box a number
>
> of
>
> > years back. You have a CD boot into memory and a system that scans the
> > memory processes that is separate to the first. Any changes result in a
> > memory reload. It can be costly (the issue) to implement, but it is also
> > very secure (as long as you do not need changes as it was not dynamic).
>
> - Your scanner could be vulnerable
> - If you need to change the hardware, your scanner could be vulnerable
> against
> unexpected new processor functions.
> - On a blackbox you never know what the program needs...
> - If you reload the memory, could lead to reseting and Denial Of Service...
>
> > Many systems are blackboxes, this is not the sole cause of security
>
> issues.
>
> > In addition, open source also has just as many flaws.
>
> I disagree. Im not pointing that blackboxes are the sole cause of security
> issues.
>
> but blackbox are vulnerable in time since:
>
> - When you modify their enviroment, you dont know what is the behavior of
> such
> device/system...
> - Every software/library/something could have discovered vulns across the
> time.
> - Every product have a lifetime, if you dont know the exact behavior, it
> cannot be replaced easily, and could lead to Denial Of Service.
> - etc.
>
> --------------------
>
> Protecting a blackbox require the knowledge of how the blackbox works and
> interact... then if you can protect a blackbox, this is not a blackbox.
>
> There are too many proofs that every blackbox have a danger itself.
>
> > ...
> > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > Information Defense Pty Ltd
> >
> >
> >
> > -----Original Message-----
> > From: Aarón Mizrachi [mailto:unmanarc () gmail com]
> > Sent: Wednesday, 27 May 2009 7:42 AM
> > To: craig.wright () information-defense com
> > Cc: security-basics () securityfocus com; 'Stephen Mullins';
> > dan.crowley () gmail com
> > Subject: Re: Security vs. Simplicity
> >
> > > Old Signed by an unknown key
> >
> > On Martes 26 Mayo 2009 16:16:01 Craig S. Wright escribió:
> > > Basically, there is a small correlation between the effects of security
> >
> > and
> >
> > > simplicity. This is complexity for its own sake will not add and may
> >
> > remove
> >
> > > security. Likewise, simplicity for its own sake will not add security.
> > >
> > > "With documentation and organization, you can cover the most of your
> > > threats."
> > > First documenting a system is an addition of complexity. It also
> > > matters how well it is done. Next there is the issue of compliance vs
> > > security. They are not the same thing. Documenting a system does not
> > > secure it.
> >
> > Agree, document does not secure it.
> >
> > The meaning of my point is... without documentation, the system are prone
> > to
> >
> > be a blackbox, and blackboxes are prone to be vulnerable.
> >
> > > "If you install any device, you must consider the maintainance of this
> > > device, you must consider the end of life of this product, you must
> > > consider the probability that this product itself gets vulnerable
>
> without
>
> > > your knowledge."
> > > This is true, but it is not an argument against simplicity or
>
> complexity.
>
> > > For the most part, the functions of simplify and security are
> > > perpendicularly polar. This is, although there is a feedback effect one
> > > aligns with a proverbial X and the other a proverbial Y axis. The real
> > > issue also comes to a definitional framework. I speak of simplicity in
> > > a Chaos/Complexity theory framework.
> > >
> > > Simplicity adds to security in human system interactions. Complex
>
> systems
>
> > > (in general) are more prone to catastrophic failure. That is they are
> > > more brittle. To understand this, you need to think how a brittle
> > > material fails. High carbon steel structures can be remarkable strong,
> > > but if they exceed their threshold only once, they shatter. Low carbon
> > > steel will bend at a lower threshold, but can be reformed. If the
> > > strength of a brittle material is sufficiently high, it does not matter
> > > that it can fail catastrophically, as the conditions will never be met.
> > >
> > > As in materials science, some of the most robust systems as hybrid
> > > composites. This is a combination of systems. This in itself is a form
>
> of
>
> > > complexity, but in the sense that simple and complex systems are
> > > enmeshed.
> > >
> > > The same applies to information systems. Brittle but strong systems can
> > > survive extremely well as long as they are sufficiently resilient to
>
> have
>
> > a
> >
> > > capacity to withstand any attack.
> > >
> > > Computer is simple analogy. "It is very simply designed. I dare you to
> >
> > find
> >
> > > a vulnerability in my computer." Easy Bios. I could keep on. Software
> > > help defend flaws in the design of systems. We have not even started on
> > > OP Code attacks against the processor. The proverbial "block" as a PC
> > > if as flawed as the computer itself.
> > >
> > > The flaw here is in software. Although we pose an NP Infeasibility
>
> issue,
>
> > > software validation can be great use. It also poses a cost. A verified
> > > system (such as in the old rainbow A tables) can be extremely
> > > resilient. The cost of such a system is however extraordinarily high.
> > >
> > > All software is complex by nature. So the issue is not of pure
> > > simplicity. Even in the face of open source code, software is not
> > > evaluated. It requires a level of complexity to account for the
> > > failings in software. Malcode, bugs, vulnerabilities etc all account
> > > for the
>
> major
>
> > > flaw in any system design. To account for this correctly requires the
> > > introduction of multiple systems. This reduces simplicity through
> > > introduced complexity, yet adds to systematic security. An example is
> > > given through an
> > > introduction of dual layers of firewall technologies with separate
> > > vendors such that neither ever suffers the same software flaw (and all
> > > firewalls have had compromises). Another example is the use of multiple
> > > anti-virus engines (such as a email gateway with one product and a
> > > separate engine on the email server and data store).
> > >
> > > To contrast this, this increase in security from multiple systems is
> > > impacted through the addition of additional human factors. More systems
> >
> > and
> >
> > > complexity make it more difficult for a single individual to run a
> >
> > security
> >
> > > system (e.g. firewalls or AV) as they require knowledge in multiple
> > > platforms and thus spend less time on either platform. This can also
>
> lead
>
> > > to an introduction of more people. Two specialists can be used (1 for
> > > each vendor). This allows the individual to specialise in a particular
> > > area again, but also takes interaction with the other person (which was
> > > previously achieved by one individual).
> > >
> > > The requirement to act in concert adds stress points to the security
> > > solution making it more brittle. This can be tempered. Training and
> > > drilling staff leads to a team approach where the effect is in an
> > > individual team rather than a group mindset. This tempering adds to
> > > security. This may (and generally does if you exclude the cost of
> > > failure) increase costs (esp. As contingency costs are not attributed
> > > to project costs).
> > >
> > > Training in itself is a source of complexity in its development. The
> > > paradox is that this addition of complexity can create a simpler and
>
> more
>
> > > robust system.
> >
> > Agree.
> >
> > And.. this could be expressed as an equation, adding more entropy lead to
> > have
> > a failure. Adding more security system helps you to avoid some threats.
> >
> > Entropy could lead the failure probability to grow exponentially.
> >
> > The answer of this question is: There is a delicate balance.
> >
> > ------------------------
> >
> > > Regards,
> > > ...
> > > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > > Information Defense Pty Ltd
> > > (http://www.information-defense.com)
> > >
> > > -----Original Message-----
> > > From: Aarón Mizrachi [mailto:unmanarc () gmail com]
> > > Sent: Wednesday, 27 May 2009 4:28 AM
> > > To: security-basics () securityfocus com;
> >
> > craig.wright () information-defense com
> >
> > > Cc: 'Stephen Mullins'; dan.crowley () gmail com
> > > Subject: Re: Security vs. Simplicity
> > >
> > > > Old Signed by an unknown key
> > >
> > > On Lunes 25 Mayo 2009 16:44:43 Craig S. Wright escribió:
> > > > Sites such as Facebook suffer not from complexity, but rather from
> > > > the model used in their creation.
> > > >
> > > > These Web 2.0 Agile based code structures (commonly Ruby based
> > > > frameworks) are most often derived from a Test After or "Tad too
> > > > late" model. The Model, View Controller framework used in Ruby is a
> > > > good framework, but it also simplifies the coding process such that
> > > > less experienced coders are used - those without the necessary
> > > > security
> >
> > coding
> >
> > > > skills.
> > > >
> > > > Your "simple" network is in fact far more complex than many larger
> > >
> > > systems.
> > >
> > > > In your example, you have touted an Integrated Firewall. Far from
> > > > simplifying the issue, a single host with all in one features is
> > > > extremely complex. Far more so than 6 individual system
> > > > (IPS/IDS/Firewall/AV/Logging/Router) based networks.
> > > >
> > > > The integration of functions on a single host increases the attack
> > > > footprint and likelihood of error.
> > >
> > > I completly agree.
> > >
> > > There is a balance... There is a right way to secure.
> > >
> > > When i said, organization and documentation are simplicity, im trying
> > > to expose the real fact of this topic.
> > >
> > > Is like an equation, if you add some extra device to improve your
> >
> > security,
> >
> > > you must measure and accept the possibility that this mechanism are
> > > itself vulnerable. Also, you must measure and accept the managment time
> > > consumption
> > >
> > > of this device, that are substracted to another important tasks.
> > >
> > > Tasks like:
> > >
> > > - Patching
> > > - User Managment
> > > - System check
> > > - Log check
> > > - And productivity
> > >
> > > With documentation and organization, you can cover the most of your
> > > threads.
> > >
> > > ----------------------------------
> > >
> > > A couple years ago, one company, trying to be secure, bought a security
> > > hardening service that includes a SNORT IDS, vlan delimitation,
> > > firewall policies, antivirus, and computers security hardening.
> > >
> > > Looking over, you must say: its a fine thing. This company its really
> > > secure.
> > >
> > > But this company failed... the last year didnt passed the ethical
> > > pentest.
> > >
> > > Without documentation, no one were doing mantainance, the company
> > > consider IDS
> > > a working blackbox defending you.... And a time ago, snort gets
> > > vulnerable (
> > >
> > > CVE-2006-5276 ), and the pentester gained access from remote.
> > >
> > > Well, im not saying: lets uninstall all the IDS's, no...
> > >
> > > Im trying to say that everything must be documented, must be planned...
> > > If you
> > > install any device, you must consider the maintainance of this device,
> > > you must consider the end of life of this product, you must consider
> > > the probability that this product itself gets vulnerable without your
> > > knowledge.
> > >
> > > Considering that, you will be able to secure a network.
> > >
> > > You can cover a lot of vulnerabilities planning with simple security
> > > strategies...
> > >
> > > But putting devices over devices, only make things worst.
> > >
> > > > ...
> > > > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > > > Information Defense Pty Ltd

-- 
Ing. Aaron G. Mizrachi P.    

http://www.unmanarc.com
Mobil 1: + 58 416-6143543
Mobil 2: + 58 424-2412503
BBPIN: 0x 247066C1

Attachment: signature.asc
Description: This is a digitally signed message part.