The Stack Overflow podcast is back! Listen to an interview with our new CEO.
10

For my company at least, full-disk encryption isn't seen as adequate for 'data at rest' requirements, as on a live system the data can de accessed without providing a key or any additional authentication information. When relying on FDE, if an attacker was able to get in, at that point it's extremely easy to steal data, and do so quickly as no other ...


8

As @Lucas said, a lawyer should be your first port of call, however from a high level I can give some guidance on areas to look at - these are a small subset: How does the organisation test their own security? Do they use approved testers, internal teams, or both? Will you have a right to audit using your own staff or consultants? How do they manage ...


7

In general, the term "at rest" is a complement to "in transit", and data is usually specified to be in one state or the other. Data "in transit" is being actively communicated, usually through a network somewhere. Data "at rest" is sat on a hard drive or in RAM, usually within a relatively safe boundary. The reason we make these distinctions is that it ...


7

Excellent question. Dealing with security issues early on -- when finding a contractor, writing a contract, during requirements definition, and when defining the architecture -- will ultimately reduce the costs of producing secure software for developers, and reduce risks and associated costs for clients. Win-win. There is a great scenario of how badly ...


7

Client bugs are bugs residing in client side programs used to connect or interact with the server: Client: Either software that runs locally on a single computer or software that accesses shared resources provided by a server over a network. Server: Computer that is configured to run software that awaits and fulfills requests from client ...


6

The classification of data as being "at rest" or "in transit" is just a usually convenient tool for risk analysis; but there is no rule which states that data is necessarily 100% at rest or 100% in transit, with a clean separation. The Lord did not boom out across the skies "let data at rest and data in transit be separate". Categories are a human creation ...


4

IANAL, but based on my experience in Y2K where with the software I looked after there were a huge number of issues, there is little scope in practice for restitution of issues - the best outcome for the client is by resolving issues with the full cooperation of the provider. The only ones whom will be better off in such disputes are the lawyers. What this ...


4

Testability is the key, and certainly helps get the QA teams buy-in if they have something to test to. I have a slightly twisted viewpoint on requirements, as I like the idea of anti-requirements. Most requirements state what the system shall/can/may do. Anti-requirements specifically state things that the system should not do, and sometimes it is useful ...


4

I'd say that there is nothing per se which would always lead to outsourced software being less secure than an in-house development but there are some common factors which may in practice lead to this commonly being the case Cost concerns. If a key factor in winning the work is low cost, then the risk of insecure software is likely to increase. Whichever ...


3

Client Side - the attacks to which client intervention would be needed. These are particularly users or any client code e.g. javascript, etc.. at flaw. All impacts are client side and doesn't affect your server data or the server state. Server Side - the attacks to which server state or server data is compromised, this in turn will mean a server side code i....


3

The nuance is subtle and not well-defined, but if you really want to make a distinction between misuse and abuse, then I'd say that abuse is "misuse with malicious intent". E.g. running while carrying a powered chainsaw is misuse; doing so on purpose in a crowded mall is abuse.


3

Full disk encryption isn't really encrypting data at rest. Data is at rest when it is sitting on the hard drive, but it is only encrypted in an FDE situation when the drive is offline. As long as you have the drive mounted for access the full disk encryption is not protecting it. FDE is good for stolen drives, it does nothing against hackers or malware with ...


2

Unless you mean something very specific by "state machine model", there is no reason why you couldn't model conflict of interest using a state machine. The Chinese Wall itself can be easily represented as a state-machine, following the traditional BLP approach: a state is defined by the set of current accesses, a function associating each object to a ...


2

Name, address, phone, and email are all Personally Identifiable Information (PII). Although it's not likely to be a regulated business, you should protect your client by encrypting this information in transit by SSL and also protecting it on the system. Ask yourself how you'd want your information to be transmitted if you were a customer. Most would think ...


2

Reasons to use HTTPS: Encryption: As @mah's comment says, HTTPS traffic is difficult to read and / or change by a man-in-the-middle. Verification of Identity: An SSL certificate is proof to the user that the content being served is actually coming from the server it purports to be. In other words, HTTPS not only encrypts the information but also tries ...


2

A lot of confusing terms and language here. For correct information risk language, please consider FAIR, or Factor Analysis of Information Risk The terminology "Threat modeling" was correctly replaced by Cigital with the term "Architectural Risk Analysis". Using `threat' here is especially incorrect. Risk assessment (e.g., OCTAVE, OCTAVE Allegro) is also ...


2

It's subjective opinion and depends on the purpose of the policy, who the policy controls and who reads it. If it helps, think about the information security policy like the HR Expenses Policy, or the Anti-Bribery Policy. I have seen specifics in the expenses policy regarding the mileage rate and general statements about submitting in time. Infosec ...


1

The level of security you receive from software is almost entirely determined by the talent and experience of the software developers, rather than the relationship you have with them. Consider two developers, let's call them A and B. A knows how to write the software very securely, and B does not. Both A and B may be hired as employees or as contractors, and ...


1

As a rule of thumb involving a third party complicates security. It does not mean the product (software or otherwise) cannot be secure, but it does add another factor into the equation. Things to consider: Quality of the staff Experience of the third party in creating software with a focus on security, i.e. the organization as a whole needs the right focus, ...


1

It's not a violation per se. I think it puts them and their equipment "in scope" for your PCI compliance efforts. Ask your QSA for clarification if you are unsure.


1

Security Specification is a subtitle in a SRS(Software Requirements Specification) report. Search "security" keyword in this sample SRS report to get better understanding: http://www.cse.chalmers.se/~feldt/courses/reqeng/examples/srs_example_2010_group2.pdf Example specification from that document: ID: QR12 TAG: CommunicationSecurity GIST: ...


1

Misuse Case: It describes the process of executing a malicious act against a system, while use case can be used to describe any action taken by the system. Abuse Case: A complete abuse case defines an interaction between an actor and the system that results in harm to a resource associated with one of the actors, one of the stakeholders, or ...


1

Misuse may be accidental, and implies that you are using the system in a way not designed. e.g., run rm -rf on your filesystem Abuse is usually premeditated and purposeful; you can abuse a system without misusing it by doing legitimate activities in an unauthorized manner. e.g., DDoS attack using legitimate requests to load a page You may be interested ...


1

This is a very general question so bare with me... I view requirements as "goals" that I want my software/hardware/whatever to meet. Thus I feel that a good requirement follows the same philosophy as a good goal. S.M.A.R.T.E.R is the golden standard. Of course some things like "Time Based" don't always fit.


1

Is solving conflict of interest a computable problem? Can we even build a Turing Machine or another type of finite state machine to model somthing like human interest and emotion? Perhaps the CSTheoy Stack Exchange is a better platform for such a question. Or perhaps State Machines and computablity is the wrong branch of mathmatics... My gut feeling is ...


Only top voted, non community-wiki answers of a minimum length are eligible