Functionality vs Security - security assurance methodology

[Joseph Reynolds]

On 2/13/20 10:36 AM, Brad Bishop wrote:
>
>> On Feb 13, 2020, at 3:15 AM, Mihm, James <james.mihm at intel.com> wrote:
>>
>> Exposing the REST D-Bus APIs via a network interface is bad practice and should be disabled by default.
> Yeah.  You are right of course.  It isn’t really the what that bothers me here it is the how.  I’m disappointed that Intel was only able to make the Redfish enabled webui work for Intel and not anyone else.
>
>> Just because it was done that way in the beginning doesn’t mean that it should remain that way.
> I don’t remember saying this?
>
>> Applications should be configured to be secure by default.
> This sounds perfectly reasonable of course but I don’t know how to implement it for OpenBMC.  I’m not even sure what it means.  Security isn’t a boolean it is a spectrum.  Show me any security posture, and I will show you one that is slightly more strict/secure.  Clearly, my security posture isn’t strict enough for Intel.  However I know there are organizations out there that have even stricter security postures than Intel.  So in the general case - how does one decide which posture should be the default, and when is ok to “break” existing usage patterns rather than “update” them for the sake of a stricter security posture?  Help me establish some rules so we can avoid this kind of bickering in the future.

Brad,

Thanks for that introduction.  We're working on a way to answer 
questions like this in the [OpenBMC security assurance workflow][] which 
promises to address all security items using world-class practices.

Yes, literally all security items.  There are some excellent references 
out there that we are trying to use.  (footnote1)

For example, a key point in the Cloud Security Industry Summit > "[CSIS 
Secure Firmware Development Best Practices][]" > "BMC" section is to 
"Document all available interfaces" specifically including Redfish 
APIs.  A security review would find the D-Bus APIs, and raise suspicion.

Most security assurance methodologies begin with an architectural review 
of the system and drill down to all external interfaces.  We need that 
for OpenBMC.  The hard part is getting the right level of abstraction 
because the use cases and details are different, so nothing is merged 
yet.  The current attempt (in review), 
[architecture/interface-overview][], describes how BMCWeb serves REST 
APIs (which includes the D-Bus APIs).  I hope we can merge this as a 
simplified view of the BMC's primary interfaces.

Anyway, that's how I see the security story playing out for OpenBMC ... 
using OpenBMC security assurance workflow as the way to organize all 
OpenBMC security documentation and talk about which pieces are 
relatively more important.  When these docs are ready, we can refer to 
them as we continue to bicker and argue in a more sophisticated way.

- Joseph

P.S. I gave my opinion about the D-Bus APIs in a separate email, 
archived here: 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020501.html

(footnote1): Don't expect any miracles though, because following the 
security assurance methodology is a lot of difficult work and requires 
cooperation between folks in different disciplines.  And we're just 
getting started.  And all the big words makes peoples' brains hurt.

[OpenBMC security assurance workflow]: 
https://github.com/openbmc/openbmc/wiki/Security-working-group#security-assurance-workflow

[CSIS Secure Firmware Development Best Practices]: 
https://github.com/opencomputeproject/Security/blob/master/SecureFirmwareDevelopmentBestPractices.md#bmc

[architecture/interface-overview]: 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/27969

> thx
> -brad