For all the great technological walls that are possible, there is one
problem that has not yet been overcome, that is the human factor problem
("only those who are interested are going to delay their busy schedules to
stop and see what is going on"). It only takes one person to make a mistake
while half asleep working on a 3am page to compromise the best technical
security, or someone intentionally doing something wrong just to get back at
someone else, or worst of all, some naive person manipulated into doing
something completely innocent that compromises security (physical or
technical) so as to open a virtual door long enough for someone else to do
just one thing. These scenarios are real in the real world. If you find a
solution, do the world a favor, don't advertise the fact, just implement
it. Keep the bad guys wondering why their human factor cracking is failing.
Lynn
P.S. I welcome replies. This is one subject that is certainly worth
discussing in this forum.
On Fri, Jun 18, 2010 at 5:45 PM, R P Herrold <
herrold@owlriver.com> wrote:
> On Fri, 18 Jun 2010, unixprgrmr01@gmail.com wrote:
>
> Cloud computing is like having sex in Time Square. Everything is viewable
>> to everyone, but only those who are interested are going to delay their busy
>> schedules to stop and see what is going on.
>>
>
> As far as encryption goes, cracking it is only a matter of time and
>> computing power. You may not be able to crack it in an amount time that
>> makes the data usable or valuable; but, it is only a matter of time, before
>> computing power & cracking algorithms catch up and allow you to crack in
>> seconds what was previously uncrackable in decades.
>>
>
> 'CloudLinux', the CentOS downstream fork is not cloud computing, although
> in their marketing puffery, they position themselves as:
> 'CloudLinux is the only commercially supported OS
> designed specifically for the service provider market'
> -- http://www.cloudlinux.com/solutions/compare/
>
> I call B*ll sh*t
>
> http://www.cloudlinux.com/support/index.php
>
> Serverity [sic; thus in the original] 1
> 2 Buiness [sic] days ...
>
> where:
>
> Severity One (Urgent)
> Catastrophic - OMG help me now. Includes loss of production, data and no
> workaround, major security breach.
>
> I'd be embarrased to have written that (putting to one side the spelling
> errors)
>
>
> <advert> PMman time to self-recovery is minutes to having the DRP back-up
> image fallback spinning and live, and depending on the care the instance
> owner took, and the depth of their purse, later fallback images. If one
> wished to buy 24x7x365, we already have trained staffing in place for 'truck
> roll' to the DC, know our pricing, and will consult and quote to serious
> inquiries. In most instances no truck roll is needed as we maintain out of
> band access to the backside network, have remotely controllable power and
> console access (KVM over IP backhaul to dedicated management servers), and
> there is not much other than re-plugging cables that we cannot do remotely
> ...</>
>
> ------------------------------------------------------
>
>
> And opinions are like belly-buttons ...
>
> 'Everything is viewable to everyone' is laughably ignorant of the reality
>
> 3DES issued (giving ca 112 bits of symmetric cipher strength) because the
> horizon showed that governmental strength mechanical attacks were 'too
> close'. FIPS 140 is in the -2 update for just this reason, and to comply at
> the highest levels and to surmount obtaining a certification lab's
> 'sign-off' on the same costs on the order of tens of millions of dollars.
> But like RHEL and CentOS a person can obtain results to the FIPS level cited
> without the certification for little more than skull sweat and testing
>
> I just generated a 2048 strength public/private key pair (asymmetrical
> crypto) as the horizon to cracking that is not within my life expectancy.
> the number of atoms in the universe are less than the number of sequential
> stir guesses needed. Frankly, without a defect in the algorithms to permit
> ruling out wide swaths of the key-space, the universe runs out of power
> before current crypto properly done. OTP does not NEED hardware RNG's
> potted in epoxy as the early BellCore reference implementation showed
>
> The cyber ninja swat team operatives getting into the data center need to
> successfully get past:
> - fob based ACL 1
> - fob based ACL 2
> - all the cameras
> - hand geometry ACL 1
> - hand geometry ACL 2
> - outer cage 1 (fob based ACL)
> - inner cage door 1 (key locked ACL)
> ... each with continuous and redundant monitoring
> 'inside' the protected loop, and echoed to the outside
> DRP site
>
> to even get to anything [i.e., the physical layer attacks] more than they
> can get sniffing and journalling all the traffic in and out of a given IP
> for a 'corpus' to crack
>
> This is far, far more than we had at the Naval Ship R and D center during
> the Nixon administration, except we do not have armed Marine guards with
> loaded M-16's at port arms at the entry point at that long ago data-center.
> All I need to do is slow them down and be alerted
>
> All management of hosts at that DC are done through SSH and certificate
> backed SSL; there are partitioning and fire-breaks, and two discrete and
> isolated back side 'God network' network segment for control that simply
> does NOT go out of the locked cabinet; it is based on an implementation that
> passed the then CISP (now PCI) credit card data security assessment,
> conducted by the author of the v2 of that specification without any
> down-tick or question at all as to the Unix/Linux part of the data security
> model and implementation. The Windows side passed because of the use of
> physically isolated network segments, VPN tunnels, proxies for application
> isolation, and use of a doubly protected physical layer
>
> _Some_ cloud computing may be performed as a public promiscuity, but I
> assure that that generalization quoted at the top this post is not
> meaningful, nor worth a damn
>
> -- Russ herrold
> http://www.pmman.com/
>
--
Best Regards,
Lynn P. Tilby
UNIX Consultant
Ph: 480 632-8635
unixprgrmr01@gmail.com
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)