Transcript Dimensions of Security Mechanisms, Architectures and Politics Walter Kriha, Hochschule der Medien Stuttgart.

Dimensions of Security
Mechanisms, Architectures and Politics
Walter Kriha, Hochschule der Medien Stuttgart
Agenda
• Warm-up: What can we learn from the T-COM OBSOC disaster?
• Threat models and security awareness
• Dimensions of Security with examples (SSO, health and job
card, dialers, trojans and the problem behind, e-voting)
• Beyond fear: why security itself is becoming a major risk (on
stupid and dangerous security)
The focus here is on understanding security in context of real problems. Security
mechanisms and technologies are introduced as we go along. Please ask if something is
not clear.
Goals
• Learn that security is an awareness problem
• show some security problems and how they can be analyzed and
solved
• show that designing security solutions is a highly social process
– with respect to developers as well as end-users
• discuss the political role of security nowadays
It-Security is so appealing to some because of its complexity, human involvement,
organizational procedures and political consequences. For others it is a nightmare for
the exact reasons. And some try to reduce its complexity by focussing on some aspects
only: network, firewall, crypto etc. and by doing so loose it completely.
OBSOC – the T-Com partner and contract web
application
cust
omer
s
Internet
web server
application
server
application
server
OBSOC
infrastructure
admins
Test
machi
nes
Partner
Services
This diagram is a conceptual reconstruction after reading the CCC documentations.
OBSOC is a rather typical web application which allows customers and t-com admins
to maintain and control customer data and associated services. It qualifies as a „selfservice“ application in e-business patterns speak. In August several severe security
problems where detected by Dirk Heringhaus (see resources) which affected customers
and external and internal services as well. The service had to be taken down and is
offline since!
OBSOC Security Problems
1. Changing URLs allowed to work around authentication and authorization (no
client data validation)
2. Password handling for customers and admins was way below standard and
allowed easy password guessing (wrong protocol, weak procedures)
3. Customers and Admins used the same entrance with the same low level
security (wrong design)
4. Implementors of OBSOC held critical data, e.g. SQL-Server backups on
private domains, including domain passwords. (Developers lacking basic
security principles)
5. It was possible to break through from web application space into windows
domain space.(Infrastructure unsafe)
from D.Heringhaus (see
resources). ConPK=vvv
would change to a
different user contract
It was easy for anybody to take over other customers data, e.g. to order new services or stop
existing services. Direct access to internal windows domains was possible from the internet.
It should be clear that the OBSOC problems are much bigger than finding a specific security
glitch in a firewall or application server – as it can happen anytime to any company.
OBSOC Security as a System
Protocol
Wrong
authentication
protocol for
admins
Lack of access
control
Implementation
Procedure
Weak password
handling
No security
Sign-Off
No filters
No security
standards and
procedures
No clean
software
architecture
No incident
response in
place
Security is the result of a multi-dimensional effort. OBSOC failed in all three
dimensions.
Basic Mistakes and Advanced Frameworks
Mistakes
•no input validation
.NET Platform
-Web services
- legacy integration
•weak and faulty authentication
-transaction enabled
•no authorization architecture
-XML support
•unprofessional behavior with respect to
-High availability
-ASP+
•critical data
•organizational problems in case of security bugs
•no secure development process
Is it the platforms fault? Huseby mentions interesting „features“ of ASP/PHP like
automatically assigning variables or performing automatic lookup in different places
but this was probably not the case here. The mistakes are too basic for this. A different
question is: did the developers UNDERSTAND the security features the platform
offers? Where they overwhelmed? There is a really stark contrast between the level of
mistakes and the high-tech platform used.see: „Using Microsoft...“ in resources
Security by Framework
Security features provided
•Support for sessions
•separate authentication
•authorization interfaces
•infrastructure integration
Problem areas
•creating a choke point for
authorization (e.g. in Struts)
•input/output validation
with descriptive
customization and external
verification (e.g. in
firewalls)
•context sensitive access
control
•organizational issues like
key handling
It is now common understanding that development platforms need to separate security
from applications as much as possible. This happens through separation of concerns
and context like in EJB/J2EE. But support for security is not yet complete and
understanding of the features on developers side is critical.
Explanations
•
•
•
•
IT-Security expertise split between network and software people
Lack of security awareness especially on developers side
Deadlines and user comfort more important than security.
Organization not geared toward secure products.
The network security people are slowly getting a better understanding of the software
development process and critical pieces like interfaces and protocol definition. And
software developers need to get a better understanding how network security,
application security, host security and user security are related.
Security as an Awareness Problem
• Cryptographic Algorithms
• Security Protocols and
Mechanisms
• Security
Policies/Principles
• Frameworks
• Domain Problems (e.g.
web)
?
web application
Most developers have a hard time to map the left side to the right side. They do not see
the security problems in the real application and therefore do not profit from knowledge
in cryptography. Worse, because they usually do not know a lot about infrastructure
(network and firewall security) they tend to overestimate the security provided through
those means. Actually, very few companies use intrusion detection or tiger teams. This
should influence the way we teach security: starting with the problems of applications
and introducing security mechanisms and solutions as needed.
User conceptual
model
Threat Models
bespoke
applications
peertopeer
model
network/inter
net threats
host security
client side
host security
server side
Historically threat models started with a focus on host security: (trojans, privilege
extension, resource stealing).The network area introduced security threats from
networking (credential stealing, sniffing, man-in-the-middle) and distributed computing
(sybil attack, censorship, tracking). The Internet model added DOS, stolen identities
and viruses. Combinations of threat models brought us DDOS and a wave of socialengineering threats. User conceptual models (phishing, klez) and bespoke (badly
designed and implemented, custom made) applications turned out to be the weakest
links in the whole chain. Nowadays a software project should no longer assume a single
threat model.
phising (credential
attacks through social
engineering)
Example: Web Threat Model
authorization errows
input /output validation
errors
certificate confusion
web-trojans
sesson
takeover
SQl injection
server value change
Browser bugs
credential attacks
(cookie/sessionID
stealiing)
virus/trojans
SSL Cipher Specs
cross-site-scripting
buffer overruns
authentication problems
maintenance problems
(e-mail to customers etc.)
A good threat model is the basis for security related design patterns which can be preimplemented in the architecture of web-development frameworks. A threat model
requires understanding of the technologies used: http, html, SSL, SQL etc.
Phishing
A typical fake-email attack (phising) which tries to extract user credentials. The real
link was to http://deutsche-bnk.info/ shown in the browser bottom line. Interestingly,
Deutsche Bank detected this case quickly and changed the image behind the embedded
image reference to a warning message.
Short Analysis of Phishing
•
•
•
•
•
Why does SSL not help? SSL does not prevent secure connections to
unintended partners.
Are the credentials stolen from the users PC? No, but this could happen
as well, e.g. through a web trojan while logged in at the server.
Would a challenge/response authentication model help? No
Would a better browser help? Possibly. Could show the link better. Could
handle the critical step of verifying the NAME/HOST in a server
certificate MUCH better.
Is it a HTML problem? In a way yes: look at the design of the <a> tag if
the real „href“ attribute matters (as in this case)
This short analysis shows that a pure host or network based threat model does not
capture the problems behind phishing. What we need is a mutual authentication
between customer and bank without a chance for the customer to mistakenly confuse
identities.
phising (credential
attacks through social
engineering)
A Possible Solution
certificate confusion
attacks on
credentials are
useless
software
secure channel
between customer
and bank
Card-Reader with display
and PIN protection for
client credentials. Includes
bank certificate
this architecture allows secure connection establishment. If a user clicks on a fake link
the bank specific smart card and the embedded reader software would not allow a
connection to be established. But on top of this it would also allow every client action
to be signed by the client. This creates non-repudiation.
Some Dimensions of Security
•
•
•
•
•
Channel based vs. object (message) based
Centralized vs. de-centralized
Usability vs. Security
Identity vs. capability
Crypto-protocol vs. it-procedure
After dealing with several different security problems these categories emerged. To me,
they organize the whole area of security and represent different approaches. The
following examples will demonstrate some of those dimensions. There are probably
many more.
Channel Based Security:SSL
Client
Certificate
Server
Certificate
Security
Association
(end-to-end)
Root CA
Certificate
Client
private key
data
•
•
•
•
•
encrpyted
data
Endpoint
(Web Service)
Cipherspecs
data
Root CA must be trusted
Client needs to match „name“ from server certificate with the intended
partner
association is end-to-end. Intermediates can only forward packages
Data are safe only during transport (no non-repudiation)
Security not as powerful as in the case of object based security
(signatures etc.)
SSL is not the silver bullet. Again, usability problems are the biggest issue: Clients
confusing names (there is NO global naming directory), servers forgetting to set proper
cipherspecs. Both partners involved need to put complete trust into the root CA.
Object Based Security: Web Services
Credentials
encrypted
data
data
Intermediate
(Web Service)
encrypted
data
data
Signature
Signature
Credentials
Credentials
Client
Security
Association
(end-to-end)
Credentials
Endpoint
(Web Service)
• Data are transported in a store-and-forward manner
• At every intermediate a secure channel ends. The data (objects)
need to carry the security information with themselves.
• Intermediates can manipulate objects but the objects can be
protected as well (signature)
Object based security allows new business models (e.g. automated supply chain
management through intermediates) because messages can be kept safe across different
channels.
Special Case: Single-Sign-On (SSO)
trusted third party
Security
Token
Issuer
Request for access
token (together
with credentials
that proof
identity)
trust relationship
Access token with
message
Client
Endpoint
(Web Service)
offline token
verification.
Optional
online check
optional liveness check
This is the „canonical“ architecture of a SSO system. It is based on the concept of a
trusted third party: all services which accept tokens put their trust in the security token
issuer that proper authentication checks where performed. The big advantage vor the
services lies in the fact that they do no longer need an expensive authentication
infrastructure.
Portal Single-Sign-On (SSO)
trusted third party
Security
Token
Issuer
trust relationship
offline token
verification.
Optional
online check
authentication
check
SSL Session ID
Client
reverse
proxy
cookie
Application
Application
Server
Application
Server
Server
Company portals are of course using their own issuer (located in the trusted computing
base of a DMZ) to check authentication. Applications do NOT check authentication.
They rely on the token as proof of successful authentication. The token itself can
contain authorization information as well (good for the performance of distributed
systems). No application server state is stored on the client – the SSL session id is used
to map e.g a state cookie to a user session. A good description can be found in the latest
IBM redbook on portal security (www.redbooks.ibm.com)
Federated Single-Sign-On
trusted third party
Security
Token
Issuer A
Request for access
token (together
with credentials
that proof
identity)
trust relationship
Security
Token
Issuer B
trust relationship
Access token with
message
Client
Endpoint
(Web Service)
offline token
verification.
Optional
online check
optional liveness check
Federated means that there is no single Security Token Issuer. Imagine the data such a
central system would collect over the time (e.g. MS Passport). Businesses are not
interested in creating such a system. An additional benefit of federation lies in support
for different security infrastructures (PKI, Kerberos) which would normally prohibit
communication.
Web Based Single-Sign-On (SSO)
5. STI creates
trusted third party token signed with
private key.
Security
3. STI requests
authentication
Token
Issuer
4. Client sends
credentials
6. STI redirects
client back to
service and
attaches token
Client
trust relationship
2. redirect to token issuer
(return address attached)
8. Service does
offline token
verification
(via public key
of STI).
Optional
online check.
Sets cookie
Endpoint
(Web Service)
1. service request (not
authenticated)
7. client repeats
request, this time with
token
Technically web based SSO is using http redirects, GET parameters and signed tokens.
Of course all connections need to be secure. A critical point is that the token always
travels through the client (browser) where it can be attacked. Single-Log-out is also
critical. More information can be found at the liberty alliance project. (see ressources)
Typical Problems of Object Based Security
•
•
•
•
•
•
Message authentication: who is the author of a message, who is the
SENDER of a message (replay attacks)
Tokens used as keys can be lost and used by somebody else
Secrets can leak when used for authentication
„Liveness“ of tokens: is an authorization or authentication token still
valid?
Token revocation
Standardization of security related information: who can understand
which crypto-methods? How are attributes/authorizations expressed?
I expect a push for object based security in the future. Web service business models,
smart card systems etc. all allow or require signed/encrypted messages. Distributed
systems (p2p) are ideally suited for message based security.
Trusted Third Parties for SSO– a good concept?
CA
trust relationship
client request, signed
Endpoint
(Web Service)
software
offline token
verification.
Optional
online check
optional liveness check
Card-Reader with display and PIN
protection for client credentials.
Includes service certificate
A card based SSO system would be much better from a privacy point of view. It would
also reduce token problems (lost, stolen etc.).
Centralized vs. Decentralized Security
Mechanisms
• central authority creates
single-point of failure.
• big privacy issues
• secure backup and
professional maintenance
• storage of large amounts
of data
• Introduction of numbering
systems (not
constitutional)
• Data under user control
• Users private key needed
to decrypt data
• Lost smartcard problem
• Reader Problem
• Size problems
• PIN problems
• Card infrastructure
expensive to build (e.g.
card issuing based on
what?)
there is no real silver bullet. Let‘s discuss the trade-offs in the german job and health
card approaches
Job Card: The Problem Space
This diagram is taken from Christiane Schultzki-Haddouti (see resources). It shows the
current data flows and media conversion problems. The architecture is a star with the
employeers responsible for the employee data. The employer gets requests for
everything to do with employment (social security, unemployment etc.). Please note:
Using channel based security most of these flows could be made secure and automated.
But this raises privacy concerns of course.
Job Card: Architecture
This diagram is taken from Christiane Schultzki-Haddouti (see resources). Looking at
the data flows the architecture is basically a publish-subscribe system with a central
storage. The system separates data storage and authorization to get data. Whoever
needs employee data needs the employee to sign a token with her private key. The
requester then sends the token together with the request to the central storage. The
central storage validates the request (using the token) and returns employee data.
Job Card Security Design
•
•
•
•
Employee data are encrypted with key from central storage facility
The central storage facility stores all employee related data.
Employees have a smart card with a key for digital signatures. They
sign requests for their data and thereby authorize the request.
Data requestors are equipped with card readers that allow employees to
insert their cards and sign requests.
Smart cards usually carry several keys for different purposes. Public keys for digital
signatures, encryption/decryption and authentication are popular. But also symmetric
keys can be stored. Access is typically secured through a PIN based system. An
unsolved problem for both job card and health card is who will be the issuer of those
cards. The issuer needs to verify identity (costly) and e.g. bank would like to re-use
their existing authentication data instead of performing a new
identification/authentication procedure.
Job Card: Security and Politics
The red line marks both a technical and a trust border. Technically it marks where the power
of the employees key ends: the employee data are stored using a storage facility key not the
employee key. This forces the employee to put trust in a) the storage facility to not accept
non-validated requests and b) the trust center to not falsely identify employees. If the
employee data would be encrypted with the employees encryption key, trust would not be
necessary. (but other things like key escrow etc.). In the current design it depends on
POLITICS only how safe the employee data really are as the whole authorization system
could be cut off without affecting technical operations. Not to forget: a publish-subscribe
architecture allows new data sinks any time...
Health System Diagram
drug eceipts,
medical
statements,
first and
second level
treatment
prepare and
accept
medical
statements
emergency
vehicles
doctors
hospitals
equipment and
emergency data
billing
information
drug receipts
health insurances
pharmacies
patients
health portals
standards for
drugs and
treatment
health prof.
organizations
billing,
payments
The german health system is characterized by many and complex relations between all
participants. Important legal constraints are a) free choice of hospital, doctor etc. for
patients and b) the right to privacy for most health related data. Loss of privacy could
lead to major problems for patients e.g. if they are diagnosed with a critical illness.
Goals for the health card
•
•
•
•
•
•
•
•
reduce paper based workflows of drug receipts and medical statements
offer live saving information (e.g. to emergency units)
create a file with all health related data of a patient, thereby improving
medical services and control
Allow patients strict control over what information they are willing to
give to other persons.
Replace the read-only current health-card which needs to be replaced
when patient data (insurance, name) change.
Save money through faster processing
Allow better control over medical treatments through the use of
qualified signatures from medical personnel (health professional card)
Prevent abuse of health insurance through people sharing cards.
Already the list of requirements is highly political: does it include shorter workflows
(e.g. by directly connecting doctors to insurences – cutting out the professional
organizations?). And it is a nice example that complex security designs need an
excellent understanding of the social and organizational context. See Warda et.al. in
resources.
Technical aspects of the health card
• qualified signature for patients
• public part with emergency info
• access controlled private part. Needs authorization through
patient.
• PIN protection
• Limited Size. Enough to hold public keys and certificates
• No certificate check against health professional certificates
• Possibly multi-function card which carries other applications
• No reader defined yet. Patients not expected to have reader
Getting private data from the card will require a health professional certificate. Access
control is an open issue: What is the proper granularity? A complete medical statement?
Parts of it – with the danger that doctors will not notice something critical? How do you
prove that a doctor has received the proper information? What if a patient is too sick to
go to the pharmacy with her card? (Delegation problem)
Alternatives for Patient Data Storage
health card
picture and
name
Central Storage
via network
The healthcard alone is too small e.g. for large numbers of x-ray images. Also the
problem of card loss is critical. Therefore a hybrid solution is considered: some data
stored directly on the card and some data stored on the network with the patients card
holding symmetric keys to the data. Patient data have a problem with asymmetric keys:
since patients are entitled to freely select medical treatment (at least in theory) a doctors
office cannot encrypt a medical statement in advance using a public key mechanism –
the receivers public key is not known yet.
Why the card reader is important
secure channel
between customer
and bank
attacks on
credentials are
useless
confirmation
software
order
digitally
signed
receipt for
drug
Internet
Pharmacy
checks
signature and
confirms
A proper drug order should update the health card with a confirmation signature from
the pharmacy. This would also allow faster reimbursement for the patient. The internet
pharmacy would therefore need a health professional certificate (could be a problem
with international pharmacies) and the patient would need a reader. Currently the health
card system plans readers in pharmacies, doctors offices etc.
Transparency and control of medical
treatments
„ There are things we don‘t even tell our
wifes...“
A campaign by the dentists professional organization against the health card:
-patient data are best kept at the doctors office
-partial data from a health card are dangerous
-neither patients nor doctors should be transparent
Control over data is the base requirement for legal actions in case a treatment did not
work. Once medical statements are signed and stored under the patients control doctors
will be made responsible for treatments. The case above shows how fierce opposition
against some aspects of the health card will be. Here dentists try to confuse the need for
transparency of medical treatment with the patients right to privacy.
Questions
• Does it make sense to use SSL with e-mail?
• Which has more risks: EC-card or credit card? For whom?
• Your company uses a fingerprint based authentication system.
How does this affect your security as an employee?
• What is the biggest problem of passwords?
• A digital signature proves what?
Before we go after usability and security as well as Identity vs. Capabilities a few
questions to check for security awareness (;-)
Usability vs. Security: some guidelines
Path of Least Resistance. The most natural way to do any
task should also be the most secure way.
Appropriate Boundaries. The interface should expose, and
the system should enforce, distinctions between objects
and between actions along boundaries that matter to the
user.
Explicit Authorization. A user's authorities must only be
provided to other actors as a result of an explicit user
action that is understood to imply granting.
Visibility. The interface should allow the user to easily
review any active actors and authority relationships that
would aect security-relevant decisions.
Revocability. The interface should allow the user to easily
revoke authorities that the user has granted, wherever
revocation is possible.to express security policies in terms
that t their goals.
Expected Ability. The interface must not give the
user the impression that it is possible to do
something that cannot actually be done.
Trusted Path. The interface must provide an
unspoofable and faithful com-munication channel
between the user and any entity trusted to
manipulate authorities on the user's behalf.
Identifiability. The interface should enforce that
distinct objects and distinct actions have
unspoofably identiable and distinguishable
representations.
Expressiveness. he interface should provide
enough expressive power (a) to describe a safe
security policy without undue diffculty; and (b) to
allow users to express security policies in terms
that t their goals.
Clarity. The effect of any security-relevant action must be
clearly apparent to the user before the action is taken.
Taken from Ka-Ping Yee, see Resources. Looks like nowadays the only ones to follow
this advice are the dialer companies. Compare the red sections with the behavior of a
browser and an associated dialer dialog.
Dialers and Usability
URL line: to be manipulated by downloaded pages
previous dialogs made the user type in OK
frequently as the default and reasonable
behavior. Now the semantics of default suddenly
change.
Type in OK in this field:
Explicit Authorization. A user's authorities must
only be provided to other actors as a result of
an explicit user action that is understood to
imply granting. OK is preset. In some
OK
cases applet or script
will
AUTOMATICALLY
send filled in page to
dialer
Path of Least Resistance. The most natural way to do any task should also be the most secu
cancel button does not work
cancel
Status line: to be manipulated by downloaded pages
some small printed stuff that
user accepts everything.
Trusted Path. The interface must provide an
unspoofable and faithful com-munication channel
between the user and any entity trusted to manipulate
authorities on the user's behalf.
Dialer companies carefully craft their dialogs and they rely on common practices from
other programs (e.g. to make the non-critical action a default or to use OK for harmless
diaglogs). The browser violates several principles of secure delegation. At least some of
the browser problems are related to the problem of identity vs. capability (ACL vs.
Keys). See the DARPA Browser evaluation for more
Identity vs. Capability or „will we ever get
rid of viruses and trojans?“
2. System
creates subject
and assigns
privileges
1. login
establishes
identity
software
3. User starts
program. OS
checks whether
user has proper
role/right by
selecting from
ALL rights of
the user.
4. Program runs
with all rights
from user
This is the way Access Control Lists work. ACLs are used by most operating systems.
The full delegation of user rights to programs allows viruses and trojans to be so
effective. With capabilities a subset of rights can be handed over to a program which
e.g. does not allow the program to „call home“. Think about it from the perspective of
trust: simply by knowing how somebody is one should not put all trust into the persons
actions. See: www.erights.org for much more information. Note that the program does
NOT consider Identity for the decision to perform some action. This is also an
important issue for privacy protection.
Cryptographic vs. Procedural Verification
-black-box system with special hardware. No paper trail, no receipt.
(Diebold voting machines). Security relies on tested releases and closed
hardware.
-black-box system with paper trail. Selected precincts are counted in
case of close votes or just randomly selected
-Open source e-voting system. Security is believed to come from source
code inspections by many people
-Black-box system with voting receipt (allows voter to control election
through public web site with her vote)
-Black-box system with voting receipt. Voters can control their vote
AND whether it was counted properly. Danger of vote buying.
The differences between those approaches are in where they put trust. Diebold requires
the voter to put trust in the systems based on procedural verification only. Voters have
no chance for external verification. At the other end of the spectrum are systems that
use cryptography (blind signatures, homomorphic encryption) to achieve verification.
This gives voters the chance for end-to-end control and makes the system itself rather
unimportant. See more: www.verifiedvoting.org
Political Aspects of Security
• The drive for authentication – a helpful concept?
• Location based services – when authorization should be enough
• Human nature, security measures and political goals.
Almost 20 years ago the german magazine „Spiegel“ had a series on data processing
and its social dangers. „Das Stahlnetz stülpt sich über uns“. For many years the success
of personal computing and later the Internet have made those questions seem rather
unimportant. Government actions after 9/11 are forcing us to watch closely over our
rights to privacy, anonymity etc.
Biometrics at airports – preventing suicide attacks?
to airplane
Body
checks
to airplane
Baggage
checks
DB with iris
scans and
authentication
data
Regular
Entrance
Iris Scan
Entrance
Is it a good idea to create a fast boarding entrance for passengers which have
themselves registered in an iris scan DB? Is authentication enough to make flights
secure? Did authentication fail on 9/11? Authorities like the concept of authentication
because it is based the fact that once an authority knows the identity of a person that
person can get PUNISHED. This idea obviously fails in the case of suicide attacks. And
for the fast boarding entrance: now suicide attackers need frequent flyer programs to
skip further controls...
Access Control – authentication needed?
location based
services
Toll systems
Ticket systems
It is important to realize that authentication is NOT neccessary for access control. It is
only convenient for authorities to always start with authentication but capability based
systems are a proof of concept for access control without identity check. The drive for
authentication becomes very visible in the case of the card based mobile phone. There
is no technical reason at all to force buyers to expose their identity – the phone calls are
prepaid. But now even Switzerland seems to require buyer authentication.
Humans and Security
• How risks are percieved depends on how spectacular the threats are, not how
likely
• A tendency to see only the good side of security measures taken.
Counterproductive side-effects etc. are not realized.
• Believe in security measures replaces effectivity measurements
• A tendency to give up rights for better security
• A tentency to direct security measures against the symptoms of a problem
and not the root cause.
Security measures can be harmless but ineffective, annoyances or outright dangerous.
Security measures work on severals levels: they can decrease real risk but are also PR
mechanisms and political statements
Examples
„Feel good security“:
• Placing military at train stations for some time after a terrorist attack.
• Send military jets over a big city after a bombing
• Put X-Ray machine in lobby
Annoyances:
• Simulate weapon searches at tourist places
Dangerous Security:
• creating information bases on the whole population (see heise news in resources)
• Ask people to report „suspicious“ neighbours
• Announce „threat levels“ to terrorize population
Security measures can be harmless but ineffective, annoyances or outright dangerous
Beyond Fear: Challenge Security
What are the assets that you want to protect?
What are the risks to those assets?
How well does the security solution mitigate those risks?
What other risks are caused by the security solution?
What costs and trade-offs does the security solution impose?
Taken from Bruce Schneiers book „Beyond Fear“. I would like to add one more: Are
there alternative solutions which do not have those counter-productive effects?
Resources (1)
•
•
•
•
•
Sverre H. Huseby, Innocent Code – A security wake-up call for Web
Programmers (in german by dpunkt). Exzellent resource on input
validation, SQL injection etc.
Bruce Schneier, Beyond Fear – shows how security can be used to
restrict rights. On stupid and dangerous security. Raises questions like:
does security measure X really make things more secure? What are the
side-effects? Get his newsletter „cryptogram“.
Kevin Mitnick, The Art of Deception. Mostly telephone based attacks
on trust based behavior. Nice cases. Shows how to play the language
games needed for deception. Shows also how critical trustestablishment really is.
Dirk Heringhaus on OBSOC. http://ds.ccc.de/083/obsoc/ Describes the
security problems found in the t-com contract and partern web
application.
Liberty Alliance Homepage: http://www.projectliberty.org/ Describes
web based SSO. You should also read the SAML docs from www.opengroup.org for possible threats in such a system.
More resources can be found on www.kriha.org
Resources (2)
•
•
•
•
•
•
•
Christiane Schultzki-Haddouti, The german job-card.
http://www.heise.de/ct/04/13/046/ Good architecture diagrams.
DIMDI resources on the health card (including the book on telematics
in the health industry) http://www.dimdi.de/de/ehealth/karte/index.htm
Dr. Frank Warda und Dr. Guido Noelle, Telemedizin und eHealth in
Deutschland: Materialien und Empfehlungen für eine nationale
Telematikplattform (free download via dimdi)
Prozahn-Datenschutz, dentist campaign against the health card:
http://www.prozahn.de/datenschutz
On usability and security: User Interaction Design for Secure
Systems, Ka-Ping Yee http://zesty.ca/sid/ Very good guidelines
for secure designs. Watch how close some of them are to the
ideas from capability groups..
A capability based browser:
http://www.combex.com/papers/darpareport/darpaBrowserFinalReport.pdf Understand the problems of
unrestricted delegation of rights. U
Using Microsoft Technology to Create Next Generation OSS-BSS
Infrastructure, www.ccc.de/datenschleuder
More resources can be found on www.kriha.org
Resources (3)
• New european initiatives to collect ALL traffic date
(telecomunication, internet etc.) without restrictions (probable
cause, persons etc.)
(http://www.heise.de/newsticker/meldung/50940
More resources can be found on www.kriha.org